Subject: [Sip] Changing SSRC/sequence numbers during a call

From: "Dhodapkar Chinmay-C23627" <[email-masked]>
Date: Wed, 11 Oct 2006 12:06:53 -0400

Hi,
 
Can the SSRC of RTP packets change midway between the call. The scenario
is that the call has been set up using the usual SIP/SDP signalling.
After this there is no further signalling between the two entities, but
the SSRC changes. Is this valid? Since nothing else changed (remote
ip/port, 
remote entity, there is no conflict of SSRCs, etc).
 
Looking forward to some inputs on this.
Regards,
Chinmay Dhodapkar
 
_______________________________________________
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: "Tom Jose - TLS , Chennai" <[email-masked]>
Date: Fri, 13 Oct 2006 09:19:09 +0530

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 9:30 PM
To: [email-masked]
Subject: Sip Digest, Vol 30, Issue 26

Send Sip mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip digest..."

Today's Topics:

   1. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Eric Rescorla)
   2. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Robert Sparks)
   3. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Eric Rescorla)
   4. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Michael Thomas)
   5. RE: Changing SSRC/sequence numbers during a call
      ([email-masked])
   6. SIP IM Client ([email-masked])
   7. Re: Changing SSRC/sequence numbers during a call (Colin Perkins)
   8. SIP IM Client ([email-masked])
   9. Request for review of draft-ietf-rohc-sigcomp-sip-03.txt
      (Gonzalo Camarillo)

----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Oct 2006 13:53:44 -0700
From: Eric Rescorla <[email-masked]>
Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
To: Robert Sparks <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, SIP <[email-masked]>,	Michael
	Thomas <[email-masked]>, Pete Cordell <[email-masked]>,	Dean
	Willis <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Robert Sparks <[email-masked]> writes:

> So, I read this to say the proposed recommendation of CRC32 as
> specified in rfc3309 is ok to go forward with.

I think this is fine.

> Based on the discussion, I think I will also point out that MD5 can
> be used (and has been used in the past),
> that its use would rely only on its collision properties, not any
> cryptographic properties, and point out that it
> is much slower than the alternative above.
>
> Any objection?

No to the choice of CRC32, but yes to the language you suggest
above. Collision-resistance is a technical term in cryptography,
the text above is quite confusing. 

Informally, the property you want is that two hashes of the
input values have a 2^(-b) chance of having the same hash
value. Formalizing this turns out to be a really knotty problem
especially if you assume (as is true in this case) that the
input strings are non-uniform. (universal hashing is one 
way around this problem).

Anyway, I think the correct language ought to be something
like this:

   A common way to create the second part of the branch parameter
   value when forking a request is to compute a hash over the
   concatenation of the Request-URI, any Route header field values
   used during processing the request and any other values used by the
   location service logic while processing this request. The hash
   should be chosen so that there is a low probability that two
   distinct sets of these parameters will collide. Because the maximum
   number of messages which need to be compared is 70 [is this right],
   the chance of a collision is low even with a relatively small hash
   value, such as 32 bits. CRC-32 [REF] is a specific acceptable
   function, as is MD5 [REF].  Note that MD5 is being chosen purely
   for non-cryptographic properties.  An attacker who can control the
   inputs in order to produce a hash collision can attack the
   connection in a variety of other ways.

-Ekr

------------------------------

Message: 2
Date: Wed, 11 Oct 2006 16:05:57 -0500
From: Robert Sparks <[email-masked]>
Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
To: EKR <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, SIP <[email-masked]>,	Michael
	Thomas <[email-masked]>, Pete Cordell <[email-masked]>,	Dean
	Willis <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Thanks Ekr!

inline.

On Oct 11, 2006, at 3:53 PM, Eric Rescorla wrote:

> Robert Sparks <[email-masked]> writes:
>
>> So, I read this to say the proposed recommendation of CRC32 as
>> specified in rfc3309 is ok to go forward with.
>
> I think this is fine.
>
>
>> Based on the discussion, I think I will also point out that MD5 can
>> be used (and has been used in the past),
>> that its use would rely only on its collision properties, not any
>> cryptographic properties, and point out that it
>> is much slower than the alternative above.
>>
>> Any objection?
>
> No to the choice of CRC32, but yes to the language you suggest
> above. Collision-resistance is a technical term in cryptography,
> the text above is quite confusing.
I was being too sloppy - sorry.

>
> Informally, the property you want is that two hashes of the
> input values have a 2^(-b) chance of having the same hash
> value. Formalizing this turns out to be a really knotty problem
> especially if you assume (as is true in this case) that the
> input strings are non-uniform. (universal hashing is one
> way around this problem).
>
> Anyway, I think the correct language ought to be something
> like this:
>
>    A common way to create the second part of the branch parameter
>    value when forking a request is to compute a hash over the
>    concatenation of the Request-URI, any Route header field values
>    used during processing the request and any other values used by the
>    location service logic while processing this request. The hash
>    should be chosen so that there is a low probability that two
>    distinct sets of these parameters will collide. Because the maximum
>    number of messages which need to be compared is 70 [is this right],
yes, but I'll replace messages with a phrase that says
"via branch parameters in a given message" but with better wordsmithing.
>    the chance of a collision is low even with a relatively small hash
>    value, such as 32 bits. CRC-32 [REF] is a specific acceptable
>    function, as is MD5 [REF].  Note that MD5 is being chosen purely
>    for non-cryptographic properties.  An attacker who can control the
>    inputs in order to produce a hash collision can attack the
>    connection in a variety of other ways.
_Thank you_ for the text!

RjS

> -Ekr

------------------------------

Message: 3
Date: Wed, 11 Oct 2006 14:16:02 -0700
From: Eric Rescorla <[email-masked]>
Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
To: Robert Sparks <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, SIP <[email-masked]>,	Michael
	Thomas <[email-masked]>, Pete Cordell <[email-masked]>,	Dean
	Willis <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Robert Sparks <[email-masked]> writes:

> Thanks Ekr!
>
> inline.
>
> On Oct 11, 2006, at 3:53 PM, Eric Rescorla wrote:
>
>> Robert Sparks <[email-masked]> writes:
>>
>>> So, I read this to say the proposed recommendation of CRC32 as
>>> specified in rfc3309 is ok to go forward with.
>>
>> I think this is fine.
>>
>>
>>> Based on the discussion, I think I will also point out that MD5 can
>>> be used (and has been used in the past),
>>> that its use would rely only on its collision properties, not any
>>> cryptographic properties, and point out that it
>>> is much slower than the alternative above.
>>>
>>> Any objection?
>>
>> No to the choice of CRC32, but yes to the language you suggest
>> above. Collision-resistance is a technical term in cryptography,
>> the text above is quite confusing.
> I was being too sloppy - sorry.
>
>>
>> Informally, the property you want is that two hashes of the
>> input values have a 2^(-b) chance of having the same hash
>> value. Formalizing this turns out to be a really knotty problem
>> especially if you assume (as is true in this case) that the
>> input strings are non-uniform. (universal hashing is one
>> way around this problem).
>>
>> Anyway, I think the correct language ought to be something
>> like this:
>>
>>    A common way to create the second part of the branch parameter
>>    value when forking a request is to compute a hash over the
>>    concatenation of the Request-URI, any Route header field values
>>    used during processing the request and any other values used by the
>>    location service logic while processing this request. The hash
>>    should be chosen so that there is a low probability that two
>>    distinct sets of these parameters will collide. Because the maximum
>>    number of messages which need to be compared is 70 [is this right],
> yes, but I'll replace messages with a phrase that says
> "via branch parameters in a given message" but with better wordsmithing.

Right. I actually meant "inputs" :)

-Ekr

------------------------------

Message: 4
Date: Wed, 11 Oct 2006 15:14:46 -0700
From: Michael Thomas <[email-masked]>
Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
To: EKR <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, SIP <[email-masked]>,	Pete
	Cordell <[email-masked]>,	Robert Sparks
	<[email-masked]>,	Dean Willis
<[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Is it just me, or do others think that this warrents a SHOULD level set 
of choices?
The cost of a collision is probably some pretty weird behavior, and 
given no real
constraint we can be pretty well assured that somebody will use the lack 
of normative
language to do the wrong thing. Or am I being all too net-nannyish?

       Mike

Eric Rescorla wrote:

>Robert Sparks <[email-masked]> writes:
>
>  
>
>>So, I read this to say the proposed recommendation of CRC32 as
>>specified in rfc3309 is ok to go forward with.
>>    
>>
>
>I think this is fine.
>
>
>  
>
>>Based on the discussion, I think I will also point out that MD5 can
>>be used (and has been used in the past),
>>that its use would rely only on its collision properties, not any
>>cryptographic properties, and point out that it
>>is much slower than the alternative above.
>>
>>Any objection?
>>    
>>
>
>No to the choice of CRC32, but yes to the language you suggest
>above. Collision-resistance is a technical term in cryptography,
>the text above is quite confusing. 
>
>Informally, the property you want is that two hashes of the
>input values have a 2^(-b) chance of having the same hash
>value. Formalizing this turns out to be a really knotty problem
>especially if you assume (as is true in this case) that the
>input strings are non-uniform. (universal hashing is one 
>way around this problem).
>
>Anyway, I think the correct language ought to be something
>like this:
>
>   A common way to create the second part of the branch parameter
>   value when forking a request is to compute a hash over the
>   concatenation of the Request-URI, any Route header field values
>   used during processing the request and any other values used by the
>   location service logic while processing this request. The hash
>   should be chosen so that there is a low probability that two
>   distinct sets of these parameters will collide. Because the maximum
>   number of messages which need to be compared is 70 [is this right],
>   the chance of a collision is low even with a relatively small hash
>   value, such as 32 bits. CRC-32 [REF] is a specific acceptable
>   function, as is MD5 [REF].  Note that MD5 is being chosen purely
>   for non-cryptographic properties.  An attacker who can control the
>   inputs in order to produce a hash collision can attack the
>   connection in a variety of other ways.
>
>-Ekr
>  
>

------------------------------

Message: 5
Date: Thu, 12 Oct 2006 09:42:01 +0530
From: <[email-masked]>
Subject: RE: [Sip] Changing SSRC/sequence numbers during a call
To: <[email-masked]>,	<[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi,

SSRC is used per session as an identifier of the source. It will not be
changed in a Session.

In a session, if there is a collision with the SSRC from the other side
it should be changed (This is a very rare case!!)

Ina video call, where you have audio and video for each medium a SSRC is
used.

So what type of call are you making? Is it a multimedia call?

Questions related to RTP can be posted @ [email-masked]

HTH,

Sreeram.

________________________________

From: Dhodapkar Chinmay-C23627 [mailto:[email-masked]] 
Sent: Wednesday, October 11, 2006 9:37 PM
To: [email-masked]
Subject: [Sip] Changing SSRC/sequence numbers during a call

Hi,

Regards,

Chinmay Dhodapkar

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/sip/attachments/20061012/51e990d9/attachment.
html

------------------------------

Message: 6
Date: Thu, 12 Oct 2006 11:28:51 +0530
From: <[email-masked]>
Subject: [Sip] SIP IM Client
To: <[email-masked]>,	<[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi There
Can any one suggest me the IM client  open source which built on SIP
protocol.
An early response in this regard is appreciated.
 
Regards
Kamal
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/sip/attachments/20061012/b259a4f6/attachment.
html

------------------------------

Message: 7
Date: Thu, 12 Oct 2006 08:59:55 +0100
From: Colin Perkins <[email-masked]>
Subject: Re: [Sip] Changing SSRC/sequence numbers during a call
To: <[email-masked]> <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On 12 Oct 2006, at 05:12, <[email-masked]> wrote:
> SSRC is used per session as an identifier of the source. It will  
> not be changed in a Session.

The SSRC of a participant can change within a session if there is a  
collision (as noted below), or if the participant generates multiple  
streams within the session. For example, if a participant has two  
cameras and switches between then, the video from each camera should  
use a different SSRC [RFC 3550 section 3].

> In a session, if there is a collision with the SSRC from the other  
> side it should be changed (This is a very rare case!!)
>
>
>
> Ina video call, where you have audio and video for each medium a  
> SSRC is used.
>
> So what type of call are you making? Is it a multimedia call?
>
>
>
> Questions related to RTP can be posted @ [email-masked]

Or to the IETF AVT working group <[email-masked]> which designed RTP.

Colin

------------------------------

Message: 8
Date: Thu, 12 Oct 2006 13:43:45 +0530
From: <[email-masked]>
Subject: [Sip] SIP IM Client
To: <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi There
Can any one suggest me the IM client  open source which built on SIP
protocol.
An early response in this regard is appreciated.
 
Regards
Kamal
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/sip/attachments/20061012/9c1c8b1a/attachment.
html

------------------------------

Message: 9
Date: Thu, 12 Oct 2006 13:32:33 +0300
From: Gonzalo Camarillo <[email-masked]>
Subject: [Sip] Request for review of
	draft-ietf-rohc-sigcomp-sip-03.txt
To: sip <[email-masked]>
Cc: [email-masked], Adam Roach <[email-masked]>, "Surtees,
	Abigail" <[email-masked]>,	Dean Willis
	<[email-masked]>, "West,	Mark"
<[email-masked]>,
	"Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>,
	[email-masked], Carsten Bormann <[email-masked]>,
Keith
	Drage <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Folks,

we have just submitted the following draft, which defines how to use
SigComp with SIP. Until it appears in the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-ietf-rohc-sigcomp-sip-03.txt

We would like to ask the SIP WG to review this draft; especially
Sections 6 through 10.

Thanks,

Gonzalo

------------------------------

End of Sip Digest, Vol 30, Issue 26
***********************************
DISCLAIMER 
The contents of this e-mail and any attachment(s) are confidential and intended for the 

named recipient(s) only. It shall not attach any liability on the originator or HCL or its 

affiliates. Any views or opinions presented in this email are solely those of the author and 

may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, 

dissemination, copying, disclosure, modification, distribution and / or publication of this 

message without the prior written consent of the author of this e-mail is strictly 

prohibited. If you have received this email in error please delete it and notify the sender 

immediately. Before opening any mail and attachments please check them for viruses and 

defect.