The callflow is voice mail service isn't it?

[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  |                   |                |
> |<------------------|                   |                |
> |(2) 200 offer1     |                   |                |
> |------------------>|                   |                |
> |                   |(3) INVITE offer1  |                |
> |                   |------------------>|                |
> |                   |(4) 200 OK answer1 |                |
> |                   |<------------------|                |
> |                   |(5) ACK            |                |
> |                   |------------------>|                |
> |(6) ACK answer1    |                   |                |
> |<------------------|                   |                |
> |(7) RTP            |                   |                |
> |.......................................|                |
> |(8) BYE            |                   |                |
> |------------------>|                   |                |
> |(9) 200 OK         |                   |                |
> |<------------------|                   |                |
>                      |(10) re-INV no SDP |                |
>                      |------------------>|                |
>                      |(11) 200 offer2    |                |
>                      |<------------------|                |
>                      |(12) INV offer2'   |                |
>                      |----------------------------------->|
>                      |(13) 200 answer2'                   |
>                      |<-----------------------------------|
>                      |(14) ACK                            |
>                      |----------------------------------->|
>                      |(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
> undefined 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,  <[EMAIL PROTECTED]> 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] <[EMAIL PROTECTED]> wrote:
>>>  > Hi,
>>>  >
>>>  > Can anybody give guideline about the UAS Behavior as below:
>>>  >
>>>  >  UAC                               UAS
>>>  > <========== Session Establised=========>
>>>  >   |                                 |
>>>  >   |-----Re-invite(w/o SDP offer)--->|
>>>  >   |                                 |
>>>  >   |<----200 OK(Codec1, Codec2)------|
>>>  >   |                                 |
>>>  >   |-------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
>   

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to