There are multiple "pbx" type products that put a B2BUA in the middle,
between the phones. Some of these prefer to use offerless invites most
of the time. It gives a chance to assess what features and capabilities
the phones want to use, and possibly insert transcoders, etc.
I don't want to get into the pros and cons of doing things this way -
I'm just saying it is out there.
Paul
[EMAIL PROTECTED] wrote:
> Hi Paul,
>
> Can you kindly provide some other applicaiton contexts?
> And, I totally agree with you that it is out of the current standards.
> So I was just wondering what do other SIP implementor handle such a
> case. :)
>
> Thanks a lot.
>
> Alex Zhang
> ESN: 6-554-8782
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 21, 2008 12:00 PM
> To: Alex Zhang (GDNTRND)
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [email protected]
> Subject: Re: Re :Re: [Sip-implementors] SDP Error Handling --
> UnsupportedcodecinSDP Answer
>
>
>
> [EMAIL PROTECTED] wrote:
>> :).
>>
>> I think this is a kind of error handling scenario. What I want to
>> discuss is actually hitting the usage of the "re-invite without SDP
>> offer". I only find that the 3rd party call control service has the
>> usage of such scenario.
>
> There are a lot of potential uses of this. Most of the ones I can think
> of involve some sort of B2BUA, but those show up in many different
> contexts. So don't assume that what you have seen is the only use there
> is. Just make your code do the right thing in general.
>
>> If the controller does not send the ACK with correct codec value to
>> the UA2 as SDP answer to the 200OK(re-invite) w/ SDP offer, how does
>> UA2 react properly?
>
> There is no formal definition of "properly" here because you are outside
> of what the standards address.
>
> You should complain to the manufacturer of the offending device. If you
> must deal with such a thing then you will have to make your code do what
> it must to work with the offending device.
>
>> Should UA2 choose to continue
>> the call or notify the controller by a BYE message that the error
>> occurs and then release the call?
>
> Take your pick.
>
> Paul
>
>> Alex Zhang
>> ESN: 6-554-8782
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, March 20, 2008 9:11 PM
>> To: Alex Zhang (GDNTRND)
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>> [EMAIL PROTECTED]; [email protected]
>> Subject: Re: Re :Re: [Sip-implementors] SDP Error Handling --
>> Unsupportedcodec inSDP Answer
>>
>> I've now gotten a little lost in where this is going.
>>
>> Exactly what do you want to know? The original scenario you gave was
>> invalid. Do you want to know how to act when interacting with a device
>
>> that is doing invalid things? Or are you looking for permission to do
>> invalid things.
>>
>> IMO you may do as you wish in response to invalid behavior. But the
>> main thing you should probably do is complain to the manufacturer of
>> the device that is behaving incorrectly - get them to fix it.
>>
>> Paul
>>
>> [EMAIL PROTECTED] wrote:
>>> Thanks for Ramprakash's nice input. Do you have any ideas on the
>>> behaviors on that how a UA inteacts with the 3pcc under a error
>>> scenario, as what I have be concerned with that the ACK carries a
>>> mismatch codec value to answer the 200ok(SDP offer).
>>>
>>>
>>> /*Alex Zhang*
>>> ESN: 6-554-8782/
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --
>>> *From:* Ramprakash V [mailto:[EMAIL PROTECTED]
>>> *Sent:* Wednesday, March 19, 2008 3:00 PM
>>> *To:* Alex Zhang (GDNTRND); [EMAIL PROTECTED]; [EMAIL PROTECTED];
>
>>> santosh.k
>>> *Subject:* Re :Re: [Sip-implementors] SDP Error Handling --
>>> Unsupported codec inSDP Answer
>>>
>>> Hi Alex,
>>>
>>> On the basis of the call flows you have given I feel the controller
>>> behaves more like a b2bua(back to back user agent).The b2bua can also
>
>>> be used to initiate calls(third party call control).
>>>
>>> In normal proxy or one to one call scenarios the reinvite can be sent
>
>>> for session negotiation or for a session refresh with session expires
>
>>> header.But the uas should be supporting that header then the 200 ok
>>> will not have an offer sdp and the call can continue with the already
>
>>> established sdps.On the other hand if the uas does not support that
>>> header then it will behave like a normal session negotiation.
>>>
>>> But in b2bua when it initiates a call by acting as third party call
>>> controller the initial invites or the reinvites may or maynot have an
>
>>> sdp(rfc 3725).
>>>
>>> I believe this should be the way it works.Guys what do u think??
>>> regards,
>>> Ramprakash
>>>
>>>
>>>
>>>
>>> On Tue, 18 Mar 2008 17:25:40 0800 [EMAIL PROTECTED] wrote
>>> Actually, this question is related to the usage of the Re-invite w/o
>>> SDP offer. So far, I have idea about the context of this kind of
>>> re-invite, except, in this forum, Yongxin ever raised such a scenario
>
>>> in which the re-invite w/o SDP offer is used.
>>>
>>> His thread is
>>>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg14825.
>>> ht
>>> ml
>>> Below is the callflow, however I don't know what the service is:
>>>
>>> A Controller B C
>>> |(1) INVITE no SDP | | |
>>> || | |
>>> | |(3) INVITE offer1 | |
>>> | |------------------>| |
>>> | |(4) 200 OK answer1 | |
>>> | || |
>>> |(6) ACK answer1 | | |
>>> || | |
>>> |(9) 200 OK | | |
>>> || |
>>> |(11) 200 offer2 | |
>>> ||
>>> |(13) 200 answer2' |
>>> ||
>>> |(15) ACK answer2 | |
>>> |------------------>| |
>>> |(16) RTP |
>>> |................|
>>>
>>>
>>> Alex Zhang
>>> ESN: 6-554-8782
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>>> Sent: Monday, March 17, 2008 8:34 PM
>>> To: Alex Zhang (GDNTRND)
>>> Cc: [EMAIL PROTECTED]; [email protected]
>>> Subject: Re: [Sip-implementors] SDP Error Handling -- Unsupported
>>> codec inSDP Answer
>>>
>>>
>>>
>>> [EMAIL PROTECTED] wrote:
>>> > Thanks,
>>> >
>>> > So, the UAS can not take for granted that the previous SDP is to
>>> be
>>>> used for both ways if it just ignores codec3 without terminating the
>>> session.
>>> > Right?
>>>
>>> Once you get outside the valid behavior specified by the standards
>>> you
>>> can take nothing for granted. You are by definition dealing with
>>> behavior.
>>>
>>> Paul
>>>
>>> > Alex Zhang
>>> > ESN: 6-554-8782
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Vikram Chhibber [mailto:[EMAIL PROTECTED]
>>> > Sent: Monday, March 17, 2008 4:40 PM > To: Alex Zhang (GDNTRND)
>>> Cc: [EMAIL PROTECTED]; [email protected]
>>> > Subject: Re: [Sip-implementors] SDP Error Handling -- Unsupported
>>>> codec in SDP Answer > > If the UAS continues the call, the
>>> behavior is implementation specific.
>>> > This could lead to one way media or no media at all. It may happen
>>>> that UAC sending codec-3 which UAS is not able to understand and UAS
>>>> sending previous negotiated codec that UAC may be able to process.
>>> > RFC 3264 specifies how answer should be created and does not >
>>> explicitly mentions about what to do in this scenario. Terminating
>>> the
>>>> session is the most logical thing to do in my opinion.
>>> > http://www.veraznetworks.com/
>>> > /Vikram
>>> > On Mon, Mar 17, 2008 at 1:56 PM, wrote:
>>> >> What will happen if the UAS decide to continue the call?
>>> >> Actually, the UAC may have some errors, such as select a wrong
>>> codec > >> outside the codec list of the SDP Offer. Will the
>>> continuing call >> cause a mismatch of the stream?
>>> >>
>>> >> Please also give reference about this beahvior? Thanks, >> >>
>>>>> Alex Zhang >> ESN: 6-554-8782 >> >> >> >> >> -----Original
>>> Message----- >> From: Madhav Bhamidipati [mailto:[EMAIL PROTECTED]
>>>>> Sent: Monday, March 17, 2008 4:20 PM >> To: Alex Zhang (GDNTRND)
>>>>> Cc: [email protected]
>>> >> Subject: Re: [Sip-implementors] SDP Error Handling -- Unsupported
>>>>> codec in SDP Answer >> >> I wonder if it sends ACK in the first
>>> place with an unrelated codec.
>>> >> If UAC sends a kind of
>>> >> 4XX then call continuation is still possible, i.e UAS has still
>>> an
>>>>> option to continue the call with old parameters.
>>> >>
>>> >> If it sends ACK then UAS sends BYE with no other option.
>>> >>
>>> >> Madhav
>>> >>
>>> >> On 3/17/08, [EMAIL PROTECTED] wrote:
>>> >> > Hi,
>>> >> >
>>> >> > Can anybody give guideline about the UAS Behavior as below:
>>> >> >
>>> >> > UAC UAS
>>> >> >
>>> >> > | |
>>> >> > |-----Re-invite(w/o SDP offer)--->| >> > | | >> > |> > | |
>>>> |-------ACK (Codec 3)------------>| >> > | | >> > | | >> > >> >
>>> Will UAS release the call or continue the call with the previous >
>>> SDP?
>>> >> > Thanks,
>>> >> >
>>> >> > Alex
>>> >> > _______________________________________________
>>> >> > 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
>>> >>
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>>
>>>
>>> ICL
>>> <http://adworks.rediff.com/cgi-bin/AdWorks/click.cgi/www.rediff.com/s
>>> i
>>> gnature-home.htm/[EMAIL PROTECTED]/2069675_2062292/2069751/1?PARTNER
>>> =
>>> 3&OAS_QUERY=null>
>>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
