Hi Roshan,
It is perfectly OK for ACK to contain all the codec. In those scenario's both the UA's
will select the first codec as the negotiated codec..
Thx,
--Arun.
------- Original Message -------
Sender : [email protected]<[email protected]>
Date : Feb 24, 2012 00:35 (GMT+09:00)
Title : Sip-implementors Digest, Vol 107, Issue 7
Send Sip-implementors mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip-implementors digest..."
Today's Topics:
1. Re: Expected behavior for an INVITE sent without an offer
(I?aki Baz Castillo)
2. Re: Expected behavior for an INVITE sent without an offer
(Kevin P. Fleming)
3. Re: Expected behavior for an INVITE sent without an offer
(Paul Kyzivat)
4. Re: Expected behavior for an INVITE sent without an offer
(I?aki Baz Castillo)
5. Re: Regarding simultaneous Sessiontimernegotiations
(OKUMURA Shinji)
6. Regarding SDP answer in ACK (Roshan nampeli)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Feb 2012 23:11:21 +0100
From: I?aki Baz Castillo
Subject: Re: [Sip-implementors] Expected behavior for an INVITE sent
without an offer
To: Paul Kyzivat
Cc: "[email protected]"
Message-ID:
Content-Type: text/plain; charset=UTF-8
2012/2/22 Paul Kyzivat
> If I was in the position of needing to construct a temporary offer, with
> no ability to handle media myself, and no knowledge of what the caller
> might be looking for or what is likely to be offered later, I would be
> inclined to offer audio with G.711 and a black holed IPv4 media address.
> Or maybe I would offer both audio and video and a whole bunch of codecs,
> still with black holed IPv4 address. But if possible it would be better
> to tailor the offer to the sorts of capabilities that will be offered later.
And all of this makes the requirement of an SDP offer in the first 1XX
response really a pain, am I wrong?
BTW, what about if a SIP proxy/server receives an INVITE with no SDP
offer and "Require: 100rel" and the SIP proxy/server wants to reply a
181 "Call Is Being Forwarded" or 182 "Queued" before ruting the call
to the appropriate destination (imagine an specific SIP application
server for an incoming call-center)? why should such a SIP
server/proxy include an SDP offer in the 181/182 response? It makes no
sense at all, and hence the requirement within RFC 3262 is wrong
(IMHO).
Maybe this annoying requirement is inheritance from RFC 3261 in which
is stated that "the first reliable response to an INVITE MUST contain
an SDP answer/offer (depending on the presence of SDP offer in the
INVITE or not)?
Regards.
--
I?aki Baz Castillo
------------------------------
Message: 2
Date: Wed, 22 Feb 2012 16:59:14 -0600
From: "Kevin P. Fleming"
Subject: Re: [Sip-implementors] Expected behavior for an INVITE sent
without an offer
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 02/22/2012 04:11 PM, I?aki Baz Castillo wrote:
> 2012/2/22 Paul Kyzivat
>> If I was in the position of needing to construct a temporary offer, with
>> no ability to handle media myself, and no knowledge of what the caller
>> might be looking for or what is likely to be offered later, I would be
>> inclined to offer audio with G.711 and a black holed IPv4 media address.
>> Or maybe I would offer both audio and video and a whole bunch of codecs,
>> still with black holed IPv4 address. But if possible it would be better
>> to tailor the offer to the sorts of capabilities that will be offered later.
>
> And all of this makes the requirement of an SDP offer in the first 1XX
> response really a pain, am I wrong?
>
> BTW, what about if a SIP proxy/server receives an INVITE with no SDP
> offer and "Require: 100rel" and the SIP proxy/server wants to reply a
> 181 "Call Is Being Forwarded" or 182 "Queued" before ruting the call
> to the appropriate destination (imagine an specific SIP application
> server for an incoming call-center)? why should such a SIP
> server/proxy include an SDP offer in the 181/182 response? It makes no
> sense at all, and hence the requirement within RFC 3262 is wrong
> (IMHO).
>
> Maybe this annoying requirement is inheritance from RFC 3261 in which
> is stated that "the first reliable response to an INVITE MUST contain
> an SDP answer/offer (depending on the presence of SDP offer in the
> INVITE or not)?
Yes, that's exactly where it comes from. The usage of 100rel/PRACK turns
that 181/182 response into a 'reliable response'.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email protected] | SIP: [email protected] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
------------------------------
Message: 3
Date: Wed, 22 Feb 2012 19:04:43 -0500
From: Paul Kyzivat
Subject: Re: [Sip-implementors] Expected behavior for an INVITE sent
without an offer
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/22/12 5:59 PM, Kevin P. Fleming wrote:
> On 02/22/2012 04:11 PM, I?aki Baz Castillo wrote:
>> 2012/2/22 Paul Kyzivat
>>> If I was in the position of needing to construct a temporary offer, with
>>> no ability to handle media myself, and no knowledge of what the caller
>>> might be looking for or what is likely to be offered later, I would be
>>> inclined to offer audio with G.711 and a black holed IPv4 media address.
>>> Or maybe I would offer both audio and video and a whole bunch of codecs,
>>> still with black holed IPv4 address. But if possible it would be better
>>> to tailor the offer to the sorts of capabilities that will be offered later.
>>
>> And all of this makes the requirement of an SDP offer in the first 1XX
>> response really a pain, am I wrong?
>>
>> BTW, what about if a SIP proxy/server receives an INVITE with no SDP
>> offer and "Require: 100rel" and the SIP proxy/server wants to reply a
>> 181 "Call Is Being Forwarded" or 182 "Queued" before ruting the call
>> to the appropriate destination (imagine an specific SIP application
>> server for an incoming call-center)? why should such a SIP
>> server/proxy include an SDP offer in the 181/182 response? It makes no
>> sense at all, and hence the requirement within RFC 3262 is wrong
>> (IMHO).
>>
>> Maybe this annoying requirement is inheritance from RFC 3261 in which
>> is stated that "the first reliable response to an INVITE MUST contain
>> an SDP answer/offer (depending on the presence of SDP offer in the
>> INVITE or not)?
>
> Yes, that's exactly where it comes from. The usage of 100rel/PRACK turns
> that 181/182 response into a 'reliable response'.
AFAIK that language came before my time.
If we had it to do over, I suspect that requirement would be relaxed.
But we are where we are, and changing it would probably cause more grief
than living with it. (The problem being backward compatibility with any
implementations that depend upon this.)
Thanks,
Paul
------------------------------
Message: 4
Date: Thu, 23 Feb 2012 09:40:30 +0100
From: I?aki Baz Castillo
Subject: Re: [Sip-implementors] Expected behavior for an INVITE sent
without an offer
To: "Kevin P. Fleming"
Cc: [email protected]
Message-ID:
Content-Type: text/plain; charset=UTF-8
2012/2/22 Kevin P. Fleming
> Yes, that's exactly where it comes from. The usage of 100rel/PRACK turns
> that 181/182 response into a 'reliable response'.
Ok, but why should the 181/182 include an SDP offer in case the INVITE
has not? that does not make sense.
--
I?aki Baz Castillo
------------------------------
Message: 5
Date: Thu, 23 Feb 2012 19:13:07 +0900
From: OKUMURA Shinji
Subject: Re: [Sip-implementors] Regarding simultaneous
Sessiontimernegotiations
To: [email protected]
Cc: Paul Kyzivat
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
Paul Kyzivat
Wed, 22 Feb 2012 15:35:28 -0500
>On 2/22/12 5:54 AM, OKUMURA Shinji wrote:
>> Hi Paul,
>>
>> I think that the following rule should be applied to Session-Expires.
>>
>> RFC3311/5.1 Sending an UPDATE
>> If a UA
>> uses an UPDATE request or response to modify the remote target while
>> an INVITE transaction is in progress, and it is a UAS for that INVITE
>> transaction, it MUST place the same value into the Contact header
>> field of the 2xx to the INVITE that it placed into the UPDATE request
>> or response.
>>
>>
>> But a particular crossing case is not avoidable as yet.
>>
>> A B
>> | |
>> |re-INV |
>> |------------------------------>|
>> | 18x-rel|
>> b1|<------------------------------|b1
>> | 2xx|
>> | /---------------|b2/s1
>> |UPD / |
>> |=============/================>|
>> | / 2xx(UPD)|
>> b3/s2|<==========/===================|b3/s2
>> | / |
>> * b2/s1|<--------/ |
>> |ACK |
>> |------------------------------>|
>> | |
>>
>> UA-A may need a new UPDATE or re-INVITE to confirm a common view
>> of Session-Expires.
>
>In this case, only B has enough info to realize there is a problem.
>So if it discovers that there is an ambiguity it would need to initiate
>another session timer refresh.
There is another crossing case.
A B
| |
|re-INV |
|------------------------------>|
| 18x-rel|
b1|<------------------------------|b1
| 2xx|
| /-------------|b2/s1
| / UPD|
b3/s2|<==============/===============|b3/s2
|2xx(UPD) / |
|=============/================>|
| / |
b2/s1|<----------/ |
|ACK |
|------------------------------>|
| |
The simplest rule I think is,
between sending 2xx to INVITE and receiving ACK,
1. UA does not send an UPDATE.
2. UA does not respond 2xx to an UPDATE.
Regards,
Shinji.
>> Paul Kyzivat
>> Mon, 20 Feb 2012 12:24:08 -0500
>>> On 2/20/12 8:43 AM, Brett Tate wrote:
>>>>> The RFC 4028 allows 2 simultaneous session timer
>>>>> negotiations i.e with Re-Invite and Update. So the following
>>>>> combinations are possible for session refresh request.
>>>>
>>>>
>>>>
>>>>> The session timers (session interval and session expires)
>>>>> will be started based on the session expires header values
>>>>> in the 2xx response of refresh request.
>>>>>
>>>>> The cross over of the response messages is also possible
>>>>> (Response for the first refresh request received after the
>>>>> response for the second refresh request).
>>>>
>>>> Correct. As discussed within the following and related threads,
>>>> this is one of the potential SIP race conditions.
>>>>
>>>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-October/025881.html
>>>>
>>>>
>>>>> The session expires in the 2xx response must be validated
>>>>> by the stack as per the rules defied in RFC4028.
>>>>>
>>>>> What would be the most elegant way of handling such scenarios:
>>>>
>>>> Assume that the latest received/sent 2xx is the most accurate.
>>>> If overly concerned that the race condition may cause the session
>>>> to not be refreshed in time, you can do something like pick the
>>>> lowest interval among the choices and act as the refresher.
>>>>
>>>> If you want to see the issue fixed or addressed as a BCP, you
>>>> might raise the issue within the dispatch or sipcore working
>>>> groups to see if anyone else wants this and similar race condition
>>>> ambiguities resolved. If I recall correctly, this was not one of
>>>> the issues fully addressed by RFC 6141 or RFC 5407.
>>>
>>> I'm generally supportive of working out all the ambiguities in the sip
>>> specs. But some cases are so minor and theoretical that they don't
>>> warrant the work required to work out and publish the clarification. I'd
>>> be interested in hearing descriptions of instances of this problem "in
>>> the wild".
>>>
>>> It would be appropriate to file an errata against the draft. That will
>>> mean that the issue will at least be addressed if/when the draft is
>>> revised in the future.
>>>
>>> (BTW, Its my impression that session timer is vastly over-used. There is
>>> no need for two UAs to use session timer to monitor the session between
>>> them: each may send an in-dialog request at any time to verify it. The
>>> primary value of session timer if for record-routed proxies.)
>>>
>>> Thanks,
>>> Paul
------------------------------
Message: 6
Date: Thu, 23 Feb 2012 13:09:49 +0000
From: Roshan nampeli
Subject: [Sip-implementors] Regarding SDP answer in ACK
To: "'[email protected]'"
Message-ID:
Content-Type: text/plain; charset=iso-8859-1
Hello,
In the SIP sdp offer/answer scenario suppose A sends INVITE without SDP to B.
B then replies with all the codecs it supports (say 0,8,4,18).
Then is it proper for A to reply in ACK with all codecs (say 0,8,18,4) ?
A-----------INVITE(no sdp)----------> B
A<------------100 trying--------------B
A<------------180ringing-------------B
A<-----------200Ok(0,8,4,18)--------B
A-----------ACK(0,8,18,4)----------->B
Thanks in advance,
Roshan.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
End of Sip-implementors Digest, Vol 107, Issue 7
************************************************
|
|
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
