Please find the response inline.

Rgds,
Gururaj K.

Inactive hide details for "Jakub Jablonski XB \(AL/EAB\)" <[EMAIL PROTECTED]>"Jakub Jablonski XB \(AL/EAB\)" <[EMAIL PROTECTED]>


          "Jakub Jablonski XB \(AL/EAB\)" <[EMAIL PROTECTED]>

          02/24/2006 03:51 PM


To

<[EMAIL PROTECTED]>

cc

<[email protected]>

Subject

RE: [Sip-implementors] SDP offer in response to UPDATE or PRACK

Hi,

is this clear from RFCs, that you shouldn't send an offer in the last
message in the transaction?
>>>> If the offer is recd in the last message in the txn then how can the

other UA send the answer for this Offer ??

Consider the case =>
UA1 -> call Estd -> UA2
UA1 -> UPDATE (No SDP) -> UA2
UA1 <- 2xx of UPDATE (Offer) <- UA2         ---> Offer sent in 2xx of UPDATE

In this scneario, is there any way for UA1 to complete this offer/answer model ?

UA1 cannot send UPDATE request with answer, since UPDATE is used for modifying the
already established media ie it can carry the new Offer.

(In the RPR scenarios, PRACK is the only request in which UA can generate answer since its part of
 1xx reliable response txn)

From the other side, how should the UA treat the SDP, if it is received
in the last message in the transaction?
>>>>> In the above scenario for example, UA1 can discard the SDP coming in 2xx of UPDATE

and continue with the call or since the UA2 has misbehaved it can also terminate the call
as well.  


Jakub


________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: 24 February 2006 11:11
To: Jakub Jablonski XB (AL/EAB)
Cc: [email protected];
[EMAIL PROTECTED]
Subject: Re: [Sip-implementors] SDP offer in response to UPDATE
or PRACK



Hi jakub,

There should be at most one offer/answer per transaction.Please
refer the following link.

http://www1.ietf.org/mail-archive/web/sip/current/msg11956.html
<
http://www1.ietf.org/mail-archive/web/sip/current/msg11956.html>

so, 2xx for PRACK or 2xx for UPDATE cannot carry the SDP since
there is no subsequent message in the corresponding
transaction to carry the answer.

if at all offer/answer exchange is required in the below
scenarios then it can happen b/w

i) PRACK and its 2xx
ii) UPDATE and its 2xx.

Rgds,
Gururaj

Inactive hide details for "Jakub Jablonski XB \(AL/EAB\)"
<[EMAIL PROTECTED]>"Jakub Jablonski XB \(AL/EAB\)"
<[EMAIL PROTECTED]>




"Jakub Jablonski XB \(AL/EAB\)"
<[EMAIL PROTECTED]>
Sent by:
[EMAIL PROTECTED]

02/24/2006 03:08 PM



To

<[email protected]>


cc




Subject

[Sip-implementors] SDP offer in response to UPDATE or PRACK
 

Hi,
is it possible to send an new offer in the 2xx response to
UPDATE or
PRACK?

Case 1:

       UAC                   UAS
        | F1  INVITE (SDP)    | <- The offer in offer/answer
model
        |-------------------->|
        | F2 1xx-rel (SDP)    | <- The answer in offer/answer
model
        |<--------------------|
        | F3   PRACK          |
        |-------------------->|
        | F4 2xx PRA (SDP)    | <- The offer in offer/answer
model ?
        |<--------------------|
        | F5  UPDATE (SDP)    | <- The answer in offer/answer
model ?
        |<--------------------|
        | F6 2xx UPDATE       |
        |-------------------->|

Case 2:

       UAC                   UAS
        | F1  INVITE (SDP)    | <- The offer in offer/answer
model
        |-------------------->|
        | F2 1xx-rel (SDP)    | <- The answer in offer/answer
model
        |<--------------------|
        | F3    PRACK         |
        |-------------------->|
        | F4  2xx PRACK       |
        |<--------------------|
        | F5    UPDATE        |
        |<--------------------|
        | F6 2xx UPDATE (SDP) | <- The offer in offer/answer
model ?
        |-------------------->|
        | F7  UPDATE (SDP)    | <- The answer in offer/answer
model ?
        |<--------------------|
        | F8 2xx UPDATE       |
        |-------------------->|

These cases are not mentioned in
draft-sawada-sipping-sip-offeranswer-00.txt,
but I didn't find anything in RFCs that would forbid them.


Thanks,
Jakub

_______________________________________________
Sip-implementors mailing list
[email protected]

https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors



*********************** FSS-Unclassified ***********************




*********************** FSS-Unclassified ***********************

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

Reply via email to