Subject: RE: [Sip] RE: [Sip-implementors] Early media query

From: "Darshan Bildikar" <[email-masked]>
Date: Tue, 3 Oct 2006 10:58:16 +0530

Quoting RFC 3264 Section 8

   Nearly all aspects of the session can be modified.  New streams can
   be added, existing streams can be deleted, and parameters of existing
   streams can change.  When issuing an offer that modifies the session,
   the "o=" line of the new SDP MUST be identical to that in the
   previous SDP, except that the version in the origin field MUST
   increment by one from the previous SDP

Why I am saying there is a problem with this is because

In the first answer you are probably giving the caller the announcement
server SDP (i.e. something like o=mediaserver) and then later updating it
with the callee SDP (i.e. something like o=calleeside). If you don’t have a
B2BUA in between that actually changes the origin line of SDP (i.e. to
something like o=APPSERVER) then the flows would actually be invalid because
of this restriction. 

The flows that are described are generally used. I am not saying that they
must not be used. What I am saying is that the RFC 3264 places a restriction
on them in terms of origin line. 

However, I don’t think this restriction is valid, coz if a change the IP is
allowed why not a change in origin line? 

This is what I am trying to get clarified. 

________________________________________
From: Manpreet Singh [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 9:56 AM
To: Darshan Bildikar; 'Retesh Chadha'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sip-implementors] Early media query
Importance: High

I would say 3 makes total sense as the Re-invite is happening after a dialog
is complete so not sure why the spec wont allow it. So it would be more or
less a mid call change ( in confirmed state ) happening from a callee side
which would be the application server trying to bridge the call to the
called party skipping the announcement server. 3 should work fine and the
origin field has to be changed because now the call needs to be bridged to
the called party which is a whole new endpoint supporting different codecs
with different connection identifiers etc.
I'd say why not just send the 200OK with the answer to the initial offer in
the Invite and then play the annoucement and then bridge using a re-invite.
Unless you are trying to save the time charged till the annoucement is
played, which a lot of prepaid apps try to do, then this thing gets
complicated. I guess in that case, the application server can send the
answer in rel-183 and then the moment the call needs to be bridged, send a
200Ok and a re-invite, which is exactly what is shown in (3). 
M 
-----Original Message----- 
From: Darshan Bildikar [mailto:[email-masked]] 
Sent: Monday, October 02, 2006 11:56 PM 
To: 'Retesh Chadha'; [email-masked] 
Cc: [email-masked]; [email-masked] 
Subject: [Sip] RE: [Sip-implementors] Early media query 
I don't think that even Method 3 and 4 are OK because they will involve a
change in the origin line parameter of the SDP and that is not allowed as
per the RFC. 
BTW, what was the rationale behind not allowing the origin line to change? 
It makes implementing apps like prepaid and CRBT very difficult. Could
someone please throw some light on this? 
-----Original Message----- 
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Retesh Chadha

Sent: Monday, October 02, 2006 5:46 PM 
To: [email-masked] 
Cc: [email-masked]; [email-masked] 
Subject: Re: [Sip-implementors] Early media query 
Hi Udit 
Of all the methods you have specified, Method 1 and 2 are wrong as per the
RFC which states that the sdp of all the provisional and 2xx response of
INVITE should be same if they are present.
Both Method 3 and 4 look fine, with method 4 being better because in that
case 200 ok for INVITE is only sent when the final negotiation (call media)
is done.
Hope this helps. 
-- 
With Regards 
Retesh Chadha 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Darshan Bildikar" <[email-masked]>
Date: Tue, 3 Oct 2006 10:54:47 +0530

with the callee SDP (i.e. something like o=calleeside). If you don't have a

However, I don't think this restriction is valid, coz if a change the IP is
allowed why not a change in origin line? 

  _____  

M 

-----Original Message----- 

Hi Udit 

Hope this helps. 
-- 
With Regards 
Retesh Chadha 

On 10/2/06, [email-masked] <[email-masked]> wrote: 
> Hi, 
> 
> I want to made an application where we can use early media for playing 
> initial in-band announcements, and then finally connecting the caller to 
> actual callee (eg prepaid card application). 
> 
> I want to know which is the correct way to support this as per SIP RFC. 
> 
> Method 1: 
> 
> 
>                 Caller                        Callee 
>                   |                             | 
>                   |                             | 
>                   |(1) INVITE with offer        | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |(2) 183 with answer 1        | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(3) 200 OK with SDP          | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(4) ACK                      | 
>                   |---------------------------->| 
>                   |                             | 
> 
> 
> (2) contains SDP of announcement server 
> (3) contains SDP of callee 
> 
> 
> Method 2: 
> 
>                                        Caller Callee 
>                   |                             | 
>                   |                             | 
>                   |(1) INVITE with offer        | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |(2) 183 with answer 1        | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(3) PRACK                    | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |(4) 200 PRACK                | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(5) 200 INVITE with sdp      | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(6) ACK                      | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |                             | 
>                   |                             | 
> 
> (2) contains SDP of announcement server 
> (5) contains SDP of callee 
> 
> 
> Method 3: 
> 
>        Caller                        Callee 
>                   |                             | 
>                   |                             | 
>                   |(1) INVITE with offer        | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |(2) 183 with answer 1        | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(3) PRACK                    | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |(4) 200 PRACK                | 
>                   |<----------------------------| 
>                   |(5) 200 OK                   | 
>                   |<----------------------------| 
>                   |                             | 
>                   |(6) ACK                      | 
>                   |---------------------------->| 
>                   |                             | 
>                   |(7)Re-INVITE with SDP        | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(8) 200 OK with SDP          | 
>                   |---------------------------->| 
>                   |                             | 
>                   |(9) ACK                      | 
>                   |---------------------------->| 
> 
> (2) contains SDP of announcement server 
> (5) contains no SDP 
> (7) contains SDP of callee 
> (8) contains answer of caller for callee offer 
> 
> Her, UDATE can also be used instead of Re-invites. 
> 
> Method 4: 
> 
>                                            Caller Callee 
>                   |                             | 
>                   |                             | 
>                   |(1) INVITE with offer        | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |(2) 183 with answer 1        | 
>                   |<----------------------------| 
>                   |                             | 
>                   |                             | 
>                   |(3) PRACK                    | 
>                   |---------------------------->| 
>                   |                             | 
>                   |                             | 
>                   |(4) 200 PRACK                | 
>                   |<----------------------------| 
>                   |(5) UPDATE (callee offer)    | 
>                   |<----------------------------| 
>                   |                             | 
>                   |(6) 200 UPDATE (answer)      | 
>                   |---------------------------->| 
>                   |                             | 
>                   |(7) 200 INVITE                   | 
>                   |---------------------------->| 
>                   |                             | 
>                   |(8) ACK                      | 
>                   |---------------------------->| 
> 
> 
> In this case, when callee answers, UPDATE is sent to caller to negoitate 
> audio with caller, and then 200 OK is sent for the initial INVITE. 
> 
> Regards, 
> Udit 
> Sip-implementors mailing list 
> [email-masked] 
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors 
> 
_______________________________________________ 
Sip-implementors mailing list 
[email-masked] 
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Oct 2006 11:11:59 -0400

OK, I agree with you that 3 and 4 are invalid if the 2nd offer isn't a 
suitable modification of the first answer, and that is probably 
impractical if the announcement server and the final target are independent.

The way you get around that is to either use flow 2, with different 
to-tags, or else you a flow something like a 3pcc transfer. In those 
flows, you send an offerless reinvite to the caller, and then send that 
as an offer to the target, then take the answer from the target and send 
it as answer to the caller. To work it out you need to expose more 
detail about the interactions between the various components.

	Paul