On 2/24/12 4:23 AM, Arun Yadav wrote:
> 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..
It is not required that they will use the first codec.
Multiple codecs may be used. A common example of this is when
telephone-events is one of the codecs.
If you require that only a single codec be used, then you should make
another offer, including only the one you want out of those agreed by
the first offer.
Thanks,
Paul
> 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]"
> , Brett Tate
>
> 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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
