[Sip-implementors] SDP offer answer model

[isshed]

Hi All,

I have 1 basic query regarding ofer-answer model


Phone1 is sending the offer with 2 audio mlines and 2 video mline like
as follows.


m=audio 3342 RTP/SAVP 0 8 127
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=audio 3342 RTP/AVP 0 8 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=video 5544 RTP/SAVP 109
a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42800d
m=video 5544 RTP/AVP 109
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42800d

and phone 2 is responding with all the 4 m lines as follows

m=audio 4344 RTP/SAVP 0 8 127
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
m=audio 4344 RTP/AVP 0 8 119
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:119 telephone-event/8000
a=fmtp:119 0-15
m=video 7878 RTP/SAVP 109
a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42800d
m=video 7878 RTP/AVP 109
a=sendrecv
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010; sar=13




Which m line should phone1 select to send and receive audio and video.

let me know is query is not clear.


Thanks,

[Mayank Kamthan]

I think the first audio line and the first video line in the answer should
be taken as the negotiated codecs.

Thanks,
Mayank.

Mayank Kamthan


On Wed, Apr 16, 2014 at 12:21 PM, isshed <isshed.sip at gmail.com> wrote:

> Hi All,
>
> I have 1 basic query regarding ofer-answer model
>
>
> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
> as follows.
>
>
> m=audio 3342 RTP/SAVP 0 8 127
> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=audio 3342 RTP/AVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=video 5544 RTP/SAVP 109
> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
> m=video 5544 RTP/AVP 109
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
>
> and phone 2 is responding with all the 4 m lines as follows
>
> m=audio 4344 RTP/SAVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=audio 4344 RTP/AVP 0 8 119
> a=sendrecv
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:119 telephone-event/8000
> a=fmtp:119 0-15
> m=video 7878 RTP/SAVP 109
> a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
> m=video 7878 RTP/AVP 109
> a=sendrecv
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010;
> sar=13
>
>
>
>
> Which m line should phone1 select to send and receive audio and video.
>
> let me know is query is not clear.
>
>
> Thanks,
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

[Katsidoniotis, Manolis (NSN - US/Irving)]

I think this happens with codecs. The first one from each list would be the selected and would be initially used unless re-offer or switch on the fly tales place.

However in the case of m-lines (ie. multiple negotiated streams) I'm under the impression that unless port is 0 in any of them then "all" m-lines are expected to be simultaneously active and should send/receive streams using the first negotiated codec.
According to my understanding, it is the responsibility of the enc/decoders to multiplex the streams as needed for the end user.

M

On Apr 16, 2014 2:19 AM, ext Mayank Kamthan <mkamthan at gmail.com> wrote:
I think the first audio line and the first video line in the answer should
be taken as the negotiated codecs.

Thanks,
Mayank.

Mayank Kamthan


On Wed, Apr 16, 2014 at 12:21 PM, isshed <isshed.sip at gmail.com> wrote:

> Hi All,
>
> I have 1 basic query regarding ofer-answer model
>
>
> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
> as follows.
>
>
> m=audio 3342 RTP/SAVP 0 8 127
> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=audio 3342 RTP/AVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=video 5544 RTP/SAVP 109
> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
> m=video 5544 RTP/AVP 109
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
>
> and phone 2 is responding with all the 4 m lines as follows
>
> m=audio 4344 RTP/SAVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=audio 4344 RTP/AVP 0 8 119
> a=sendrecv
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:119 telephone-event/8000
> a=fmtp:119 0-15
> m=video 7878 RTP/SAVP 109
> a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
> m=video 7878 RTP/AVP 109
> a=sendrecv
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010;
> sar=13
>
>
>
>
> Which m line should phone1 select to send and receive audio and video.
>
> let me know is query is not clear.
>
>
> Thanks,
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

[Brett Tate]

> Which m line should phone1 select to send and
> receive audio and video.

>From an offer/answer perspective, all of the m lines.

--


This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.

[Gaurav Kumar]

Hi,

This Offer-Answer is use-case of supporting multiple m-line for SRTP. The answerer does support SAVP (for media encryption).
Ideally, Answerer should keep the port zero for audio and video m-lines with RTP/AVP and non-zero port for audio and video m-lines with RTP/SAVP (if the answerer want to establish SRTP call with the Offerer)

Offerer can accept all the m-lines in the answer, and then send reinvite where it can update m-line with port zero for RTP/AVP for audio and video m-lines.

>From RFC perspective, the answerer is behaving correctly.

Thanks,
Gaurav

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Brett Tate
Sent: Wednesday, April 16, 2014 1:49 PM
To: isshed; sip-implementors
Subject: Re: [Sip-implementors] SDP offer answer model

> Which m line should phone1 select to send and receive audio and video.

>From an offer/answer perspective, all of the m lines.

--


This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

[Brett Tate]

Hi,

If I recall correctly, there are MMUSIC RFCs (such as maybe RFC 6871)
which can potentially be used to clearly communicate to answerer that it
prefers only specific combinations of audio and video to be successfully
answered. This could potentially help avoid the need for subsequent
offer/answer negotiation to 0 out the extra audio and video media.

> -----Original Message-----
> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
> implementors-bounces at lists.cs.columbia.edu] On Behalf Of Gaurav Kumar
> Sent: Wednesday, April 16, 2014 4:27 AM
> To: isshed
> Cc: sip-implementors
> Subject: Re: [Sip-implementors] SDP offer answer model
>
> Hi,
>
> This Offer-Answer is use-case of supporting multiple m-line for SRTP.
> The answerer does support SAVP (for media encryption).
> Ideally, Answerer should keep the port zero for audio and video m-lines
> with RTP/AVP and non-zero port for audio and video m-lines with
> RTP/SAVP (if the answerer want to establish SRTP call with the Offerer)
>
> Offerer can accept all the m-lines in the answer, and then send
> reinvite where it can update m-line with port zero for RTP/AVP for
> audio and video m-lines.
>
> From RFC perspective, the answerer is behaving correctly.
>
> Thanks,
> Gaurav
>
> -----Original Message-----
> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
> implementors-bounces at lists.cs.columbia.edu] On Behalf Of Brett Tate
> Sent: Wednesday, April 16, 2014 1:49 PM
> To: isshed; sip-implementors
> Subject: Re: [Sip-implementors] SDP offer answer model
>
> > Which m line should phone1 select to send and receive audio and
> video.
>
> From an offer/answer perspective, all of the m lines.
>
> --
>
>
> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information.
> If you are not the intended recipient and have received this email in
> error, please notify BroadSoft, Inc. immediately by replying to this
> message, and destroy all copies of this message, along with any
> attachment, prior to reading, distributing or copying it.
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> This is confidential Ittiam property.
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--


This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.

[Seshagiri Kondaveti]

Hi

I believe It depends on implementation also. The client can send reinvite with port zero for unwanted m-lines or it can send SRTP directly.
We have tested RTP/AVPF and RTP/AVP with 4 m-lines ,if the answerer responds with 4 valid m-lines then we prefer RTP/AVPF and starts sending media. Our customer don't want lockdown reinvite so we implemented in this way.


Regards
Sesh

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Brett Tate
Sent: Wednesday, April 16, 2014 3:05 PM
To: Gaurav Kumar; isshed; sip-implementors
Subject: Re: [Sip-implementors] SDP offer answer model

Hi,

If I recall correctly, there are MMUSIC RFCs (such as maybe RFC 6871) which can potentially be used to clearly communicate to answerer that it prefers only specific combinations of audio and video to be successfully answered. This could potentially help avoid the need for subsequent offer/answer negotiation to 0 out the extra audio and video media.

> -----Original Message-----
> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
> implementors-bounces at lists.cs.columbia.edu] On Behalf Of Gaurav Kumar
> Sent: Wednesday, April 16, 2014 4:27 AM
> To: isshed
> Cc: sip-implementors
> Subject: Re: [Sip-implementors] SDP offer answer model
>
> Hi,
>
> This Offer-Answer is use-case of supporting multiple m-line for SRTP.
> The answerer does support SAVP (for media encryption).
> Ideally, Answerer should keep the port zero for audio and video
> m-lines with RTP/AVP and non-zero port for audio and video m-lines
> with RTP/SAVP (if the answerer want to establish SRTP call with the
> Offerer)
>
> Offerer can accept all the m-lines in the answer, and then send
> reinvite where it can update m-line with port zero for RTP/AVP for
> audio and video m-lines.
>
> From RFC perspective, the answerer is behaving correctly.
>
> Thanks,
> Gaurav
>
> -----Original Message-----
> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
> implementors-bounces at lists.cs.columbia.edu] On Behalf Of Brett Tate
> Sent: Wednesday, April 16, 2014 1:49 PM
> To: isshed; sip-implementors
> Subject: Re: [Sip-implementors] SDP offer answer model
>
> > Which m line should phone1 select to send and receive audio and
> video.
>
> From an offer/answer perspective, all of the m lines.
>
> --
>
>
> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information.
> If you are not the intended recipient and have received this email in
> error, please notify BroadSoft, Inc. immediately by replying to this
> message, and destroy all copies of this message, along with any
> attachment, prior to reading, distributing or copying it.
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> This is confidential Ittiam property.
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--


This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

[Paul Kyzivat]

I read a number of the replies to this, but couldn't find an obvious
place to jump in, so I'm just replying here.

An offer multiple audio and/or video m-lines does not mean that they are
*alternatives*. Absent some explicit indication, there is no way to know
what the offerer's intent is in offering them, nor does the offerer know
what the answerer's intent is in accepting them.

In the given example, if the offerer only intends to use one audio and
one video, then it can arbitrarily choose one, and hope that this works
reasonably for the answerer. In that case it should do another O/A and
reject the ones it doesn't intend to use.

If you are designing phone1, and your goal is to have one audio and one
video, but you want to offer more possibilities than you can express
with one audio and one video m-line, then post back with what you are
trying to accomplish, and we can discuss recommended ways of achieving that.

Thanks,
Paul

On 4/16/14 2:51 AM, isshed wrote:
> Hi All,
>
> I have 1 basic query regarding ofer-answer model
>
>
> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
> as follows.
>
>
> m=audio 3342 RTP/SAVP 0 8 127
> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=audio 3342 RTP/AVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=video 5544 RTP/SAVP 109
> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
> m=video 5544 RTP/AVP 109
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
>
> and phone 2 is responding with all the 4 m lines as follows
>
> m=audio 4344 RTP/SAVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=audio 4344 RTP/AVP 0 8 119
> a=sendrecv
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:119 telephone-event/8000
> a=fmtp:119 0-15
> m=video 7878 RTP/SAVP 109
> a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
> m=video 7878 RTP/AVP 109
> a=sendrecv
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010; sar=13
>
>
>
>
> Which m line should phone1 select to send and receive audio and video.
>
> let me know is query is not clear.
>
>
> Thanks,
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

[isshed]

Thanks Paul and everyone ...

I am designing Phone1 to use only one audio and one video. Phone1
supports secured media as well. so it is offering both secure/non
secure to phone2 and expects phone2 to select among the given m-lines
(RTP and SRTP).

Thanks.

On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> I read a number of the replies to this, but couldn't find an obvious place
> to jump in, so I'm just replying here.
>
> An offer multiple audio and/or video m-lines does not mean that they are
> *alternatives*. Absent some explicit indication, there is no way to know
> what the offerer's intent is in offering them, nor does the offerer know
> what the answerer's intent is in accepting them.
>
> In the given example, if the offerer only intends to use one audio and one
> video, then it can arbitrarily choose one, and hope that this works
> reasonably for the answerer. In that case it should do another O/A and
> reject the ones it doesn't intend to use.
>
> If you are designing phone1, and your goal is to have one audio and one
> video, but you want to offer more possibilities than you can express with
> one audio and one video m-line, then post back with what you are trying to
> accomplish, and we can discuss recommended ways of achieving that.
>
> Thanks,
> Paul
>
>
> On 4/16/14 2:51 AM, isshed wrote:
>>
>> Hi All,
>>
>> I have 1 basic query regarding ofer-answer model
>>
>>
>> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
>> as follows.
>>
>>
>> m=audio 3342 RTP/SAVP 0 8 127
>> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:127 telephone-event/8000
>> m=audio 3342 RTP/AVP 0 8 127
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:127 telephone-event/8000
>> m=video 5544 RTP/SAVP 109
>> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
>> a=rtpmap:109 H264/90000
>> a=fmtp:109 profile-level-id=42800d
>> m=video 5544 RTP/AVP 109
>> a=rtpmap:109 H264/90000
>> a=fmtp:109 profile-level-id=42800d
>>
>> and phone 2 is responding with all the 4 m lines as follows
>>
>> m=audio 4344 RTP/SAVP 0 8 127
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:127 telephone-event/8000
>> m=audio 4344 RTP/AVP 0 8 119
>> a=sendrecv
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:119 telephone-event/8000
>> a=fmtp:119 0-15
>> m=video 7878 RTP/SAVP 109
>> a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
>> a=rtpmap:109 H264/90000
>> a=fmtp:109 profile-level-id=42800d
>> m=video 7878 RTP/AVP 109
>> a=sendrecv
>> a=rtpmap:109 H264/90000
>> a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010;
>> sar=13
>>
>>
>>
>>
>> Which m line should phone1 select to send and receive audio and video.
>>
>> let me know is query is not clear.
>>
>>
>> Thanks,
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Paul Kyzivat]

On 4/17/14 12:45 AM, isshed wrote:
> Thanks Paul and everyone ...
>
> I am designing Phone1 to use only one audio and one video. Phone1
> supports secured media as well. so it is offering both secure/non
> secure to phone2 and expects phone2 to select among the given m-lines
> (RTP and SRTP).

And what is this expected to work with?
That is probably more important than what is theoretically correct.

Thanks,
Paul

> Thanks.
>
> On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
>> I read a number of the replies to this, but couldn't find an obvious place
>> to jump in, so I'm just replying here.
>>
>> An offer multiple audio and/or video m-lines does not mean that they are
>> *alternatives*. Absent some explicit indication, there is no way to know
>> what the offerer's intent is in offering them, nor does the offerer know
>> what the answerer's intent is in accepting them.
>>
>> In the given example, if the offerer only intends to use one audio and one
>> video, then it can arbitrarily choose one, and hope that this works
>> reasonably for the answerer. In that case it should do another O/A and
>> reject the ones it doesn't intend to use.
>>
>> If you are designing phone1, and your goal is to have one audio and one
>> video, but you want to offer more possibilities than you can express with
>> one audio and one video m-line, then post back with what you are trying to
>> accomplish, and we can discuss recommended ways of achieving that.
>>
>> Thanks,
>> Paul
>>
>>
>> On 4/16/14 2:51 AM, isshed wrote:
>>>
>>> Hi All,
>>>
>>> I have 1 basic query regarding ofer-answer model
>>>
>>>
>>> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
>>> as follows.
>>>
>>>
>>> m=audio 3342 RTP/SAVP 0 8 127
>>> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:127 telephone-event/8000
>>> m=audio 3342 RTP/AVP 0 8 127
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:127 telephone-event/8000
>>> m=video 5544 RTP/SAVP 109
>>> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
>>> a=rtpmap:109 H264/90000
>>> a=fmtp:109 profile-level-id=42800d
>>> m=video 5544 RTP/AVP 109
>>> a=rtpmap:109 H264/90000
>>> a=fmtp:109 profile-level-id=42800d
>>>
>>> and phone 2 is responding with all the 4 m lines as follows
>>>
>>> m=audio 4344 RTP/SAVP 0 8 127
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:127 telephone-event/8000
>>> m=audio 4344 RTP/AVP 0 8 119
>>> a=sendrecv
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:119 telephone-event/8000
>>> a=fmtp:119 0-15
>>> m=video 7878 RTP/SAVP 109
>>> a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
>>> a=rtpmap:109 H264/90000
>>> a=fmtp:109 profile-level-id=42800d
>>> m=video 7878 RTP/AVP 109
>>> a=sendrecv
>>> a=rtpmap:109 H264/90000
>>> a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010;
>>> sar=13
>>>
>>>
>>>
>>>
>>> Which m line should phone1 select to send and receive audio and video.
>>>
>>> let me know is query is not clear.
>>>
>>>
>>> Thanks,
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors at lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

[isshed]

I want to make it inter-operable with Polycom's real presence desktop.

On Thu, Apr 17, 2014 at 6:43 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> On 4/17/14 12:45 AM, isshed wrote:
>>
>> Thanks Paul and everyone ...
>>
>> I am designing Phone1 to use only one audio and one video. Phone1
>> supports secured media as well. so it is offering both secure/non
>> secure to phone2 and expects phone2 to select among the given m-lines
>> (RTP and SRTP).
>
>
> And what is this expected to work with?
> That is probably more important than what is theoretically correct.
>
> Thanks,
> Paul
>
>
>> Thanks.
>>
>> On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyzivat <pkyzivat at alum.mit.edu>
>> wrote:
>>>
>>> I read a number of the replies to this, but couldn't find an obvious
>>> place
>>> to jump in, so I'm just replying here.
>>>
>>> An offer multiple audio and/or video m-lines does not mean that they are
>>> *alternatives*. Absent some explicit indication, there is no way to know
>>> what the offerer's intent is in offering them, nor does the offerer know
>>> what the answerer's intent is in accepting them.
>>>
>>> In the given example, if the offerer only intends to use one audio and
>>> one
>>> video, then it can arbitrarily choose one, and hope that this works
>>> reasonably for the answerer. In that case it should do another O/A and
>>> reject the ones it doesn't intend to use.
>>>
>>> If you are designing phone1, and your goal is to have one audio and one
>>> video, but you want to offer more possibilities than you can express with
>>> one audio and one video m-line, then post back with what you are trying
>>> to
>>> accomplish, and we can discuss recommended ways of achieving that.
>>>
>>> Thanks,
>>> Paul
>>>
>>>
>>> On 4/16/14 2:51 AM, isshed wrote:
>>>>
>>>>
>>>> Hi All,
>>>>
>>>> I have 1 basic query regarding ofer-answer model
>>>>
>>>>
>>>> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
>>>> as follows.
>>>>
>>>>
>>>> m=audio 3342 RTP/SAVP 0 8 127
>>>> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:127 telephone-event/8000
>>>> m=audio 3342 RTP/AVP 0 8 127
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:127 telephone-event/8000
>>>> m=video 5544 RTP/SAVP 109
>>>> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
>>>> a=rtpmap:109 H264/90000
>>>> a=fmtp:109 profile-level-id=42800d
>>>> m=video 5544 RTP/AVP 109
>>>> a=rtpmap:109 H264/90000
>>>> a=fmtp:109 profile-level-id=42800d
>>>>
>>>> and phone 2 is responding with all the 4 m lines as follows
>>>>
>>>> m=audio 4344 RTP/SAVP 0 8 127
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:127 telephone-event/8000
>>>> m=audio 4344 RTP/AVP 0 8 119
>>>> a=sendrecv
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:119 telephone-event/8000
>>>> a=fmtp:119 0-15
>>>> m=video 7878 RTP/SAVP 109
>>>> a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
>>>> a=rtpmap:109 H264/90000
>>>> a=fmtp:109 profile-level-id=42800d
>>>> m=video 7878 RTP/AVP 109
>>>> a=sendrecv
>>>> a=rtpmap:109 H264/90000
>>>> a=fmtp:109 profile-level-id=42801e; max-mbps=49000;
>>>> max-br=20010;
>>>> sar=13
>>>>
>>>>
>>>>
>>>>
>>>> Which m line should phone1 select to send and receive audio and video.
>>>>
>>>> let me know is query is not clear.
>>>>
>>>>
>>>> Thanks,
>>>> _______________________________________________
>>>> Sip-implementors mailing list
>>>> Sip-implementors at lists.cs.columbia.edu
>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>>
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors at lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>>
>

[Paul Kyzivat]

On 4/17/14 1:02 PM, isshed wrote:
> I want to make it inter-operable with Polycom's real presence desktop.

Then, an unsatisfying as it is, it may be best to first find out what
Polycom supports in this regard.

From a standards perspective, SDP capability negotiation (RFC 5939 and
friends) were designed to situations like this. But this isn't widely
deployed.

Thanks,
Paul

> On Thu, Apr 17, 2014 at 6:43 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
>> On 4/17/14 12:45 AM, isshed wrote:
>>>
>>> Thanks Paul and everyone ...
>>>
>>> I am designing Phone1 to use only one audio and one video. Phone1
>>> supports secured media as well. so it is offering both secure/non
>>> secure to phone2 and expects phone2 to select among the given m-lines
>>> (RTP and SRTP).
>>
>>
>> And what is this expected to work with?
>> That is probably more important than what is theoretically correct.
>>
>> Thanks,
>> Paul
>>
>>
>>> Thanks.
>>>
>>> On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyzivat <pkyzivat at alum.mit.edu>
>>> wrote:
>>>>
>>>> I read a number of the replies to this, but couldn't find an obvious
>>>> place
>>>> to jump in, so I'm just replying here.
>>>>
>>>> An offer multiple audio and/or video m-lines does not mean that they are
>>>> *alternatives*. Absent some explicit indication, there is no way to know
>>>> what the offerer's intent is in offering them, nor does the offerer know
>>>> what the answerer's intent is in accepting them.
>>>>
>>>> In the given example, if the offerer only intends to use one audio and
>>>> one
>>>> video, then it can arbitrarily choose one, and hope that this works
>>>> reasonably for the answerer. In that case it should do another O/A and
>>>> reject the ones it doesn't intend to use.
>>>>
>>>> If you are designing phone1, and your goal is to have one audio and one
>>>> video, but you want to offer more possibilities than you can express with
>>>> one audio and one video m-line, then post back with what you are trying
>>>> to
>>>> accomplish, and we can discuss recommended ways of achieving that.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>>
>>>> On 4/16/14 2:51 AM, isshed wrote:
>>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I have 1 basic query regarding ofer-answer model
>>>>>
>>>>>
>>>>> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
>>>>> as follows.
>>>>>
>>>>>
>>>>> m=audio 3342 RTP/SAVP 0 8 127
>>>>> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
>>>>> a=rtpmap:0 PCMU/8000
>>>>> a=rtpmap:8 PCMA/8000
>>>>> a=rtpmap:127 telephone-event/8000
>>>>> m=audio 3342 RTP/AVP 0 8 127
>>>>> a=rtpmap:0 PCMU/8000
>>>>> a=rtpmap:8 PCMA/8000
>>>>> a=rtpmap:127 telephone-event/8000
>>>>> m=video 5544 RTP/SAVP 109
>>>>> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
>>>>> a=rtpmap:109 H264/90000
>>>>> a=fmtp:109 profile-level-id=42800d
>>>>> m=video 5544 RTP/AVP 109
>>>>> a=rtpmap:109 H264/90000
>>>>> a=fmtp:109 profile-level-id=42800d
>>>>>
>>>>> and phone 2 is responding with all the 4 m lines as follows
>>>>>
>>>>> m=audio 4344 RTP/SAVP 0 8 127
>>>>> a=rtpmap:0 PCMU/8000
>>>>> a=rtpmap:8 PCMA/8000
>>>>> a=rtpmap:127 telephone-event/8000
>>>>> m=audio 4344 RTP/AVP 0 8 119
>>>>> a=sendrecv
>>>>> a=rtpmap:0 PCMU/8000
>>>>> a=rtpmap:8 PCMA/8000
>>>>> a=rtpmap:119 telephone-event/8000
>>>>> a=fmtp:119 0-15
>>>>> m=video 7878 RTP/SAVP 109
>>>>> a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
>>>>> a=rtpmap:109 H264/90000
>>>>> a=fmtp:109 profile-level-id=42800d
>>>>> m=video 7878 RTP/AVP 109
>>>>> a=sendrecv
>>>>> a=rtpmap:109 H264/90000
>>>>> a=fmtp:109 profile-level-id=42801e; max-mbps=49000;
>>>>> max-br=20010;
>>>>> sar=13
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Which m line should phone1 select to send and receive audio and video.
>>>>>
>>>>> let me know is query is not clear.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> _______________________________________________
>>>>> Sip-implementors mailing list
>>>>> Sip-implementors at lists.cs.columbia.edu
>>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>>>
>>>>
>>>> _______________________________________________
>>>> Sip-implementors mailing list
>>>> Sip-implementors at lists.cs.columbia.edu
>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>>>
>>
>

[Ozan Terzi]

http://www.ietf.org/rfc/rfc3264.txt

7 Offerer Processing of the Answer When the offerer receives the answer, it MAY send media on the accepted stream(s) (assuming it is listed as sendrecv or recvonly in the answer). It MUST send using a media format listed in the answer, and it SHOULD use the first media format listed in the answer when it does send.
Thanks,
Ozan.
On Wednesday, April 16, 2014 5:24 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:

I read a number of the replies to this, but couldn't find an obvious
place to jump in, so I'm just replying here.

An offer multiple audio and/or video m-lines does not mean that they are
*alternatives*. Absent some explicit indication, there is no way to know
what the offerer's intent is in offering them, nor does the offerer know
what the answerer's intent is in accepting them.

In the given example, if the offerer only intends to use one audio and
one video, then it can arbitrarily choose one, and hope that this works
reasonably for the answerer. In that case it should do another O/A and
reject the ones it doesn't intend to use.

If you are designing phone1, and your goal is to have one audio and one
video, but you want to offer more possibilities than you can express
with one audio and one video m-line, then post back with what you are
trying to accomplish, and we can discuss recommended ways of achieving that.

??? Thanks,
??? Paul

On 4/16/14 2:51 AM, isshed wrote:
> Hi All,
>
> I have 1 basic query regarding ofer-answer model
>
>
> Phone1 is sending the offer with 2 audio mlines and 2 video mline like
> as follows.
>
>
> m=audio 3342 RTP/SAVP 0 8 127
> a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:2222222222
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=audio 3342 RTP/AVP 0 8 127
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:127 telephone-event/8000
> m=video 5544 RTP/SAVP 109
> a=crypto:8 AES_CM_128_HMAC_SHA1_80 inline:3333333333
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
> m=video 5544 RTP/AVP 109
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d
>
> and phone 2 is responding with all the 4 m lines as follows
>
>? ? ? ? m=audio 4344 RTP/SAVP 0 8 127
>? ? ? ? a=rtpmap:0 PCMU/8000
>? ? ? ? a=rtpmap:8 PCMA/8000
>? ? ? ? a=rtpmap:127 telephone-event/8000
>? ? ? ? m=audio 4344 RTP/AVP 0 8 119
>? ? ? ? a=sendrecv
>? ? ? ? a=rtpmap:0 PCMU/8000
>? ? ? ? a=rtpmap:8 PCMA/8000
>? ? ? ? a=rtpmap:119 telephone-event/8000
>? ? ? ? a=fmtp:119 0-15
>? ? ? ? m=video 7878 RTP/SAVP 109
>? ? ? ? a=crypto:8 8 AES_CM_128_HMAC_SHA1_80 inline:4444444444
>? ? ? ? a=rtpmap:109 H264/90000
>? ? ? ? a=fmtp:109 profile-level-id=42800d
>? ? ? ? m=video 7878 RTP/AVP 109
>? ? ? ? a=sendrecv
>? ? ? ? a=rtpmap:109 H264/90000
>? ? ? ? a=fmtp:109 profile-level-id=42801e; max-mbps=49000; max-br=20010; sar=13
>
>
>
>
> Which m line should phone1 select to send and receive audio and video.
>
> let me know is query is not clear.
>
>
> Thanks,
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

>

[Brett Tate]

Hi,

Since a prior reply was emphasizing "first audio line and the first video
line", I just wanted to mention that "first media format listed in the
answer" within the RFC 3264 snippet corresponds to first "fmt" within the
"m=" line instead of "first audio line and the first video line".

RFC 4566: m=<media> <port> <proto> <fmt> ...

> -----Original Message-----
> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
> implementors-bounces at lists.cs.columbia.edu] On Behalf Of Ozan Terzi
> Sent: Friday, April 18, 2014 4:45 AM
> To: Paul Kyzivat; sip-implementors at lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] SDP offer answer model
>
> http://www.ietf.org/rfc/rfc3264.txt
>
> 7 Offerer Processing of the Answer When the offerer receives the
> answer, it MAY send media on the accepted stream(s) (assuming it is
> listed as sendrecv or recvonly in the answer). It MUST send using a
> media format listed in the answer, and it SHOULD use the first media
> format listed in the answer when it does send.
> Thanks,
> Ozan.

--


This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the intended recipient and have received this email in error,
please notify BroadSoft, Inc. immediately by replying to this message, and
destroy all copies of this message, along with any attachment, prior to
reading, distributing or copying it.