Subject: RE: [Sip] Can a transaction stateless proxy supportOutbounddraft?Ifyes, how will the response be sent back the UA behind NAT

From: "Attila Sipos" <[email-masked]>
Date: Thu, 15 Nov 2007 18:21:34 -0000

>>1.
>>> Now let's say the callee sends BYE (not the caller).
>>
>>Ok, here I see 2 options.
>>1) The BYE is sent over the flow
>>2) The BYE is sent in a traditional way (non-outbound case)
>>
>>I assume that you are talking of option 1) above.

yes.  I would have thought that it must be sent using the flow.

>>2.
>>> So my idea is that the proxy gets this and forwards it in the normal

>>> way and inserts a Via header.
>>
>>I agree.
>>
>>3.
>>> In the Via header's branch parameter, it would encode the required 
>>> flow token.
>>
>>Here is the issue : From were you get the flow token?
>>(In my previous email I mentioned 2 options... )
>>

OK I'm starting to see your problem.

The registration record stores the flow token (obviously)
And the socket id for the flow would be stored as well (for
connection-oriented
protocols). So if you received a request on that socket, you could match
that
up to one of the registration records and hence, one of the flow tokens.

(I think I am starting to see some difficulties with this)

>>4.
>>>> Then when the 200 response arrives,
>>>>> it looks at the top Via and decodes the branch parameter.  From
this 
>>>>> it knows which flow to use to forward the response.
>>
>>If you managed to add the flow token in the step above it is OK

I hope I have explained how the flow token might be mapped to the
socket.
I can now see that my idea wouldn't work for UDP.

But what if you used the gruu in the contact to match up with
the gruu of a registration?  Then the registration record tells
tells you about the flow token.  That would work wouldn't it?

Regards,
	Attila

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 15 November 2007 17:45
To: [email-masked]
Cc: Attila Sipos
Subject: RE: [Sip] Can a transaction stateless proxy
supportOutbounddraft?Ifyes, how will the response be sent back the UA
behind NAT

> I was talking about the stateless proxy putting the flow token into 
> the Via.
> I don't understand why you mentioned UA's.

  Yes, me too. I mentioned the UA because is a possible solution to pass
the flow token to the edge proxy when it handles non-register requests.

> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
> Let's say we use the "Example Message Flow".  To forward the INVITE in

> message 7, we use the existing flow created by the REGISTRATION.
> The response of message 9 gets forwarded in the normal way and as 
> defined in the outbound draft (i.e. it adds the flow token into the 
> Record-Route).

  Yes, I agree.

1.
> Now let's say the callee sends BYE (not the caller).

Ok, here I see 2 options.
1) The BYE is sent over the flow
2) The BYE is sent in a traditional way (non-outbound case)

I assume that you are talking of option 1) above.

2.
> So my idea is that the proxy gets this and forwards it in the normal 
> way and inserts a Via header.

I agree.

3.
> In the Via header's branch parameter, it would encode the required 
> flow token.

Here is the issue : From were you get the flow token?
(In my previous email I mentioned 2 options... )

4.
> Then when the 200 response
> arrives,
> it looks at the top Via and decodes the branch parameter.  From this 
> it knows which flow to use to forward the response.

  If you managed to add the flow token in the step above it is OK

  In my opinion there is a problem in step 3. In my previous email I
mentioned this case, I copy the text below :

>   To put the flow token in the Via I see 2 options : 1) ensure that 
> the UA stores the flow token and sends it in the body of every 
> request. 2) generate again the flow token for every request (very bad 
> from security point of views) and destroys the consistency of the 
> system since you can send requests for non existing flows. Note that 
> the draft mentions that the flow and the flow token is only created
with REGISTERs.

  Any ideas or comments are welcome. I was dealing with this issue for
months...

Regards,

Sergio

Quoting Attila Sipos <[email-masked]>:

>
> I was talking about the stateless proxy putting the flow token into 
> the Via.
> I don't understand why you mentioned UA's.
>
> re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt
> Let's say we use the "Example Message Flow".  To forward the INVITE in

> message 7, we use the existing flow created by the REGISTRATION.
> The response of message 9 gets forwarded in the normal way and as 
> defined in the outbound draft (i.e. it adds the flow token into the 
> Record-Route).
>
> Now let's say the callee sends BYE (not the caller).
>
> So my idea is that the proxy gets this and forwards it in the normal 
> way and inserts a Via header. In the Via header's branch parameter, it

> would encode the required flow token.  Then when the 200 response 
> arrives, it looks at the top Via and decodes the branch parameter.  
> From this it knows which flow to use to forward the response.
>
> Is this wrong?
>
> 	Attila
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 15 November 2007 16:18
> To: [email-masked]
> Cc: Attila Sipos
> Subject: RE: [Sip] Can a transaction stateless proxy support 
> Outbounddraft?Ifyes, how will the response be sent back the UA behind 
> NAT
>
>
>> But couldn't you encode the flow token into the Via's branch
> parameter?
>
>   Yes, it is possible, but the draft does not tell anything about 
> responses.
>   To put the flow token in the Via I see 2 options : 1) ensure that 
> the UA stores the flow token and sends it in the body of every 
> request. 2) generate again the flow token for every request (very bad 
> from security point of views) and destroys the consistency of the 
> system since you can send requests for non existing flows. Note that 
> the draft mentions that the flow and the flow token is only created
with REGISTERs.
>
>   I guess that the authors did not consider this issue because the UA 
> can go through the NAT, so it can always send requests and receive 
> responses normally out of the flow.
>
> Sergio
>
> Quoting Attila Sipos <[email-masked]>:
>
>>>>  That is not possible if we limit to the draft.
>>>>  Normal responses use the information in the Via header, and to use

>>>> the flow we need a flow token (that is not available in the
>> Via)...
>>
>> But couldn't you encode the flow token into the Via's branch
> parameter?
>> You'd have to make sure you didn't break SIP grammar rules (but a 
>> variation of base 64 would solve that).
>>
>> Would there be a problem with that?
>>
>> Regards,
>> Attila
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: 15 November 2007 15:14
>> To: [email-masked]
>> Cc: Attila Sipos
>> Subject: RE: [Sip] Can a transaction stateless proxy support 
>> Outbounddraft? Ifyes, how will the response be sent back the UA 
>> behind
>
>> NAT
>>
>>
>>
>>> For requests from the registered UA, the responses will be routed 
>>> back
>>
>>> to the UA using the established flow.
>>
>>   That is not possible if we limit to the draft.
>>   Normal responses use the information in the Via header, and to use 
>> the flow we need a flow token (that is not available in the Via)...
>>
>>
>> Sergio
>>
>>
>> Quoting Attila Sipos <[email-masked]>:
>>
>>>
>>> I think a stateless proxy CAN support outbound.
>>>
>>> As long as the stateless proxy can store registrations (well, what's

>>> the point if it can't) then it can keep up a flow back to any 
>>> registering UA.
>>>
>>> When it comes to routing a request to a registered UA, it will route

>>> it using the establiashed flow.  For requests from the registered 
>>> UA,
>
>>> the responses will be routed back to the UA using the established
>> flow.
>>>
>>> Can you see a problem with this?  It seems like it should work to
me.
>>>
>>> Regards,
>>> Attila
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Karthikeyan Gopal , TLS-Chennai [mailto:[email-masked]]
>>> Sent: 15 November 2007 08:06
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: [Sip] Can a transaction stateless proxy support Outbound
>> draft?
>>> Ifyes, how will the response be sent back the UA behind NAT
>>>
>>>
>>>
>>> Hi All,
>>>     Can a transaction stateless proxy support Outbound draft? If 
>>> yes,
>
>>> how will the response be sent back the UA behind NAT?
>>> Thanks & Regards,
>>> Karthikeyan.G
>>>
>>>
>>>
>>> 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.
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> --
>>> -----------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
>
>
> _______________________________________________
> 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
>

_______________________________________________
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: [email-masked]
Date: Fri, 16 Nov 2007 14:54:18 +0200

Hi,

> The registration record stores the flow token (obviously)

  It seems that you are integrating the edge proxy and registrar in  
the same code, right?

> And the socket id for the flow would be stored as well (for

  Can you confirm that you call socket id to the socket/file  
descriptor of the connection?

> up to one of the registration records and hence, one of the flow tokens.

  Good approach. I assume that you have available the socket  
descriptor in the registrar, so basically you consider storing the  
socket descriptor (number) in the registrar tables. Then perhaps using  
a flow token it is not necessary since you have available in the  
socket descriptor all the information that describes a flow (TCP case).

> I hope I have explained how the flow token might be mapped to the

  Yes if my comments above make sense..

> I can now see that my idea wouldn't work for UDP.

  Now for UDP perhaps you can consider storing the socket descriptor  
for UDP and the IP and port for the flow from the NAT.

  My point of view is that integrating the edge proxy with the  
registrar can be good as a proof of concept but not suitable for a  
production system.
  I think that this approach is not flexible in terms of scalability  
for the number of edge proxies.

  My situation is different. I considered scalability and wanted  
modularity. Then I considered an isolated edge proxy (no registrar).  
Then following the ethic of the authors I try to avoid any state as  
mentioned on section "5.2.  Generating Flow Tokens" and I can not rely  
in any storage (like the registrar bindings in your case).

  Furthermore my registrar should not store socket descriptors due  
that if the edge proxy crashes, the registrar could have a number of  
descriptor that after the crash belong to other flows.

  I generate the flow token with REGISTER and send it to the registrar  
(other node). The approach works as the draft says for incoming  
requests (to the Calle). Now when the Callee  sends requests, and the  
requests are sent over the flow, the responses of that request reach  
first the edge proxy and it can not forward them to the Callee over  
the flow, because these responses don't have the flow token (and the  
flow token is not stored in the edge proxy)...

> tells you about the flow token.  That would work wouldn't it?

  I have not background with gruu. Could you recommend what could I  
read about it?

BR
Sergio