Subject: RE: [Sip] outbound-06 submitted

From: Jeroen Van Bemmel <[email-masked]>
Date: Thu, 23 Nov 2006 10:24:06 +0100

List-SubscribeFrom [email-masked] Thu Nov 23 04:26:39 2006
Date: Thu, 23 Nov 2006 10:24:16 +0100
From: Jeroen Van Bemmel <[email-masked]>
Subject: RE: [Sip] Re: New work: Option-tag for ICE
To: Jonathan Rosenberg <[email-masked]>
Importance: normal
Cc: IETF SIP List <[email-masked]>, "Drage, Keith \(Keith\)" <[email-masked]>,
	Brian Stucker <[email-masked]>

> In the REGISTER case, I think its probably *slightly* more correct to 
use a capability and not an option tag. This is because you could have a 
third party registration, with different ICE support for different 
contacts in the registration.

(JvB) That, plus the discussion we had on the scope of require/supported being limited to the transaction.

Regards,
Jeroen 

_______________________________________________
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: "Vavilapalli Srikanth-A19563" <[email-masked]>
Date: Fri, 24 Nov 2006 20:13:45 +0800

Hi

Section 8 of the draft says: For TCP or TLS over TCP flows, determining
if the first octet of the next message in a stream is SIP or STUN is
still straightforward.  As with any stream-based protocol,
implementations need to be prepared to receive STUN messages which cross
a stream buffer boundary, and SIP and STUN messages which share the same
stream buffer.

Can anyone please elaborate more on demultiplexing of SIP and STUN
message in case of TCP? If the STUN message is in middle of the read
buffer, how can we demux these packets?

Regards
Srikanth

---

From: Fredrik Thulin <[email-masked]>
Date: Fri, 24 Nov 2006 13:22:46 +0100

Vavilapalli Srikanth-A19563 wrote:
...
> buffer, how can we demux these packets?

The STUN header (not sure that is the correct term) is fixed size - 20 
bytes if I remember correctly.

If you receive one byte that indicates this is STUN then you continue 
reading from the socket until you have received (at least) 19 more 
bytes. From the first 20 bytes you can figure out the total length of 
the STUN request.

/Fredrik

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Nov 2006 07:31:27 -0500

I'm not sure about the text in the draft is all clear but ...

A STUN message can not occur in the middle of a SIP message and  
likewise you can not have a SIP in the middle of the STUN. The  
streams, the whole messages has to be inserted into the stream before  
starting a new message regardless of the type of the message.

On Nov 24, 2006, at 7:22 AM, Fredrik Thulin wrote:

> The STUN header (not sure that is the correct term) is fixed size -  
> 20 bytes if I remember correctly.
>
> If you receive one byte that indicates this is STUN then you  
> continue reading from the socket until you have received (at least)  
> 19 more bytes. From the first 20 bytes you can figure out the total  
> length of the STUN request.
>
> /Fredrik

---

From: "Vavilapalli Srikanth-A19563" <[email-masked]>
Date: Fri, 24 Nov 2006 20:55:26 +0800

Sorry for the confusion. 

What I mean "in middle of the read buffer" is, For ex: In the first read
I received a partial SIP message and in the next TCP read if I receive
the remaining of the SIP message and followed by STUN message (in single
read, and I believe this is possible in TCP communication), then
demuxing will be difficult unless we parse the entire SIP message.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Friday, November 24, 2006 6:01 PM
To: Fredrik Thulin
Cc: Vavilapalli Srikanth-A19563; SIP WG; Rohan Mahy
Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and
SIP traffic

A STUN message can not occur in the middle of a SIP message and likewise
you can not have a SIP in the middle of the STUN. The streams, the whole
messages has to be inserted into the stream before starting a new
message regardless of the type of the message.

> From [email-masked] Fri Nov 24 07:56:07 2006
Content-class: urn:content-classes:message
Subject: RE: [Sip] outbound-06: Question on TCP demultiplexing STUN and SIP
	traffic
Date: Fri, 24 Nov 2006 20:55:26 +0800
From: "Vavilapalli Srikanth-A19563" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>, "Fredrik Thulin" <[email-masked]>
Cc: SIP WG <[email-masked]>, Rohan Mahy <[email-masked]>

Sorry for the confusion. 

What I mean "in middle of the read buffer" is, For ex: In the first read
I received a partial SIP message and in the next TCP read if I receive
the remaining of the SIP message and followed by STUN message (in single
read, and I believe this is possible in TCP communication), then
demuxing will be difficult unless we parse the entire SIP message.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Friday, November 24, 2006 6:01 PM
To: Fredrik Thulin
Cc: Vavilapalli Srikanth-A19563; SIP WG; Rohan Mahy
Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and
SIP traffic

A STUN message can not occur in the middle of a SIP message and likewise
you can not have a SIP in the middle of the STUN. The streams, the whole
messages has to be inserted into the stream before starting a new
message regardless of the type of the message.

> reading from the socket until you have received (at least)

---

From: Fredrik Thulin <[email-masked]>
Date: Fri, 24 Nov 2006 14:12:07 +0100

> demuxing will be difficult unless we parse the entire SIP message.

No, demuxing will be _impossible_ unless you parse the entire SIP 
message first.

I can't think of a single reason why one would not want to parse the 
complete SIP message first, can you please explain?

/Fredrik

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Nov 2006 17:23:23 -0800

You have the same problem reading two sip messages in a row.

Many implementations have e a simple state machine that scans past  
the headers, find the content length, then scan past the body but no  
parsing other than that. I can point you at some code if you want.

On Nov 24, 2006, at 4:55 AM, Vavilapalli Srikanth-A19563 wrote:

> likewise

---

From: "Vavilapalli Srikanth-A19563" <[email-masked]>
Date: Mon, 27 Nov 2006 13:01:12 +0800

True, without parsing entire SIP message we would not know about the
existence of STUN packets. 

The reason behind posting this question is coming more from
implementation point of view. Suppose if some implementations receive
the messages from TCP sockets in one thread and process them in other
thread contexts and if it is the responsibility of receiving thread to
demux the packets and give it to individual threads, then it would be a
problem (If the receiving thread gives the entire second read buffer to
SIP processing thread, unless there is a way to get back the remaining
buffer from SIP thread, the receive thread can not handover the STUN
packet to STUN processing thread)

When the draft mentioned the demuxing based on the first octet in case
of TCP was a strightforward solution, I thought there might be already a
simple solution for the scenario described above.

One solution I thought of was looking for STUN magic cokkie (combined
with Message Type or finger print) in each an every received packet from
the socket and distribute the packets to individual processing threads.
But then the magic cokkie part could have been split across multiple TCP
reads, so this solution won't work.

Regards
Srikanth 

-----Original Message-----
From: Fredrik Thulin [mailto:[email-masked]] 
Sent: Friday, November 24, 2006 6:42 PM
To: Vavilapalli Srikanth-A19563
Cc: Cullen Jennings; SIP WG; Rohan Mahy
Subject: Re: [Sip] outbound-06: Question on TCP demultiplexing STUN and
SIP traffic

Vavilapalli Srikanth-A19563 wrote:
> Sorry for the confusion. 
> 
> What I mean "in middle of the read buffer" is, For ex: In the first 
> read I received a partial SIP message and in the next TCP read if I 
> receive the remaining of the SIP message and followed by STUN message 
> (in single read, and I believe this is possible in TCP communication),

> then demuxing will be difficult unless we parse the entire SIP
message.

/Fredrik

---

From: [email-masked]
Date: Mon, 27 Nov 2006 13:26:53 -0500

The receiving thread must assemble the read buffers into a byte
stream, then parse the byte stream to find the message boundaries, and
copy the messages it finds into different buffers, and pass those
buffers to the processing thread.

It is a *very* general rule that when reading input from TCP, the
"read buffer" boundaries have no correspondance to *any* feature of
the data in the input stream.  The code that reads the TCP socket must
assemble the read buffers into a continuous input stream and parse
them in the way that is appropriate for the data.

You would be amused at the number of programs that die if you feed
them input on a TCP connection with one byte per TCP packet, because
the TCP stack gives one byte read buffers to the reader process, and
the reader process can't cope with that.

Dale