|Summary:||ASTERISK-09180: [patch] RTP Session id based on PID instead of network time stamp as suggested by RFC|
|Reporter:||Tjardick van der Kraan (tjardick)||Labels:|
|Date Opened:||2007-04-04 04:43:20||Date Closed:||2007-07-09 21:20:47|
|Environment:||Attachments:||( 0) chan_sip.patch|
|Description:||It seems that the chan_sip on creation of an rtp session id, uses getpid(). This is far from unique and well give problems when sending a re-invite to the same user agent to update the sdp session.|
****** ADDITIONAL INFORMATION ******
The bug poses problems when re-inviting for example a phone on the same dialog but to create a new RTP session. As the Session id is the same, the phone will no change it's RTP as it will think it is the same RTP stream.
RFC 2327 (SDP):
The method of <session id> allocation is up to the creating tool, but
it has been suggested that a Network Time Protocol (NTP) timestamp be
used to ensure uniqueness.
RFC 3264 (Offer/Answer Model SDP):
The numeric value of the session id
and version in the o line MUST be representable with a 64 bit signed
integer. The initial value of the version MUST be less than
(2**62)-1, to avoid rollovers.
|Comments:||By: Tjardick van der Kraan (tjardick) 2007-04-04 04:44:52|
I did a quick and dirty fix to turn getpid() to random() far from ideal, maybe even dangerous, but will add the patch anyways.
By: Joshua C. Colp (jcolp) 2007-04-09 07:34:41
Fixed in trunk using ast_random as of revision 60898. I'm hesitant to put it into 1.2 and 1.4 though as I've never seen this come up... if you do think it should go there though and have an example scenario (with debug/output/phone model) please reopen.