Subject: [Sipping] Re: [Sip] Questions about SDP session-id changes within a SIP dialog.

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 May 2007 11:29:10 -0400

David,

I just posted on a related subject. (Its not in the archives yet. Look 
for subject "[Sipping] Relationship between SIP session and SDP 
session".) I'm posting this reply there.

More inline.

	Paul

David Robinson wrote:
> All,
>   After reading  RFC 3725 BCP for 3rd Party Call Control it created an
> interesting question.
> 
> Is an SDP session-id tied directly to a SIP dialog and cannot change in 
> the SIP dialog?
> RFC 3725 seems to imply that but I cannot find any documentation that 
> specifically
> states this. (Because of the mapping of the o= line ).

RFC 3264 has specific language about this.

> Consider the following scenario when Early media is provided and the
> call is forwarded to another location.

I'm assuming you are using the 3pcc techniques as in RFC 3725.

> At Answer an Empty Re-Invite is 
> used perform
> End to End SDP negotiation and the B2BUA proxies the SDP (without 
> change) to
> complete the Path minimization. This causes a change in the SDP session 
> ID to the originator

If the 3pcc controller passes the SDP from one dialog to the other, thus 
causing the session id to change in an existing dialog, then it seems to 
be violating 3264.

It could fix this by rewriting the session id.

> also allowing for payload type numbers to be re-mapped. 

This is a *huge* leap of faith!

The requirement that payload type numbers not be re-mapped comes from 
3264, just as the prohibition against changing the session id does. 
Since there are no provisions for changing the session id in 3264, there 
is also no specification for what should be done if it does change.

> Without the
> possibility of changing the SDP session-id there are cases, mainly in 
> inter-vendor situations,
> that cause collision of Dynamic Payload type numbers. Unfortunately 
> trying to do all the
> remapping of payload types in the bearer stream is not a viable option.

Yes, there is a problem here. The 3pcc controller could map the payload 
type numbers between the two sides, but that would then also require 
terminating and relaying the media in order to do the mapping within the 
RTP packets.

So, I appreciate the desire for something to solve this problem. But I 
don't think it is possible to interpret the existing RFCs as allowing 
this particular solution.

> In addition to this scenario, there are scenarios (Blind Transfers for 
> one) that a newly
> added leg is originated with an Empty Initial Invite requiring the Far 
> office to send an
> initial offer and now how do you match up SDP media lines and payload types
> numbers for these?

It would be easier to discuss if you referenced the various flows in 3725.

> If changing the session-id is not the correct solution how do is this 
> solved?

There *is* a way to do this today, but not with 3pcc as described in RFC 
3725. It can by done using INVITE/Replaces to establish a new session 
replacing the old session.

Are there cases where this doesn't solve the problem?

> RFC 3264 states that payload type number MUST not change within a session
> (i.e. SDP session) but it states that the Payload type number do not 
> have to be
> the same in both directions and  thanks to H248 this is the case.
> 
> If I extend what is not in RFC3264 to say that if the upper layer 
> protocol provides
> a new session-id within a SIP dialog then I can re map the Payload type 
> numbers
> and the SDP Session-id and new SDP version number are considered valid and
> everything works.
> 
> What is the opinion of the BCP 3725 authors or those working with SIP RFCs?
> 
> Thanks
> Dave Robinson
> Alcatel-Lucent
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 

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