Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound

From: <[email-masked]>
Date: Tue, 2 Jan 2007 09:41:06 +0200

Hi,

While my email contained a lot of questions for you rather
than a clear proposal I am not sure if we interpret each
others opinion well enough to say we agree. Anyway to clarify
my opinion - I agree with the proposal given for the poll:

> Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS
> over TCP flow (retain STUN for UDP flows).
>
> Proposal 2: Make outbound registrations over UDP flows optional for
> UAs.
>
> Proposal 3: Include (in Outbound) the statement that its is
> RECOMMENDED that the outbound-proxy-set is configured to result in
> registrations over TCP or TLS whenever the UA can't accept incoming
> TCP flows. 

Do you agree with that ?

As a summary what that would mean in terms of deployments:

- Every Outbound compliant (UA or proxy) implementation MUST 
  support TCP but MAY support UDP too.

- It will be up to the deployment to select whether TCP or UDP
  (or even both) shall be used for that specific deployment.
  Supporting UDP only would have known limitations and it would
  also mean that TCP-only implementations could not be used for
  that deployment.

Erkki 

>-----Original Message-----
>From: ext Cullen Jennings [mailto:[email-masked]] 
>Sent: 31.December.2006 02:48
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Sip] Question about Poll: Proposal relating to 
>keepalive, TCP,and UDP usage in draft-ietf-sip-outbound
>
>
>It took me some time to parse through this but sounds like you and I  
>are in 100% agreement on what an acceptable solution would look like.
>
>
>On Dec 20, 2006, at 12:18 AM, <[email-masked]>  
><[email-masked]> wrote:
>
>>
>> Hi Cullen,
>>
>>>> Many PSTN gateways and Softswitches always send large INVITEs for
>>>> example,
>>>> and they will always fragment. And I might add that many very  
>>>> popular
>>>> NAT/routers don't support UDP fragmentation.
>>>
>>> Hmm - I wish we had better specifics here - I will point out there
>>> are millions of endpoints on well known residential endpoints that
>>> are working through NATs and connected to PSTN gw and softwswiches
>>> that are working over UDP.
>>
>> If so, then how would those endpoints get any benefit from Outbound ?
>> What would be the value added for those deployments if those 
>endpoints
>> would be changed as Outbound UDP compliant endpoints ? Multiple
>> registration support and new types of keepalive messages i.e. some
>> added reliability ?
>>
>> But if those endpoints and proxies anyway have to be either upgraded
>> or replaced for Outbound, then why couldn't that upgrade cover TCP
>> support as well ? What is the ultimate benefit for using UDP instead
>> of TCP for those deployments ?
>>
>>> Uh, no - I was saying that outbound over UDP is usable in 
>cases where
>>> the policy is to reject messages that are too large for UDP. I agree
>>> that limits the functionality of the communications with the UA that
>>> registered over this UDP only network but that was that deployments
>>> choice.
>>>
>>> Note what I am talking about here is all about deployments using TCP
>>> or UDP. I don't mind about if a UA has to implement both.
>>
>> Please remember that the proposal that you do not agree with was
>> like this:
>>
>>> Proposal 2: Make outbound registrations over UDP flows optional for
>>> UAs.
>>
>> Outbound over UDP would still be possible and probably supported by
>> those UA vendors who get significant gain for it. But some UAs
>> targetting to other deployments could just opt to support TCP.
>> What is wrong with that ?
>>
>> If it is the deployments choice to limit the functionality of the
>> communications with the UA registered, why could it not be possible
>> for the specific closed deployments to administratively (or  
>> technically)
>> limit the deployed UAs to be such that implement UDP ? Why would you
>> mandate ALL the implemented UAs to support UDP for Outbound ? Those
>> deployments could just tell the users not to aqcuire any UAs which
>> only support Outbound with TCP, if the proxies (or operator policy)
>> does not support TCP (or does not support persistent TCP 
>connections).
>>
>>>> You mean a UA will open two connections, one
>>>> for UDP and another for TCP? I fail to see why on earth
>>>> anybody would do this instead of just using a single TCP 
>connection.
>>>
>>> I think the folks that favor these approach would use a scheme where
>>> the UDP connection was long lived and the TCP connection was short
>>> lived for the large messages. The advantages of this would be to get
>>> the scaleability and reliability schemes that are easier 
>with UDP yet
>>> still be able to do large messages.
>>
>> Please remember the Outbound draft does make such a scheme possible !
>> If the UA does NOT have a long lived persistent TCP connection
>> available, there is no way for the proxy to get the UA to open
>> such connection or for the proxy itself open such a TCP connection
>> towards the UA via the NAT when a large message arrives destined
>> to the UA. So if the UA does not keep the TCP connection open
>> all the time, it has to live with the limitation of not being
>> able to receive SIP requests bigger than MTU if the NAT discards
>> fragmented UDP packets.
>>
>> P.S. Actually there is such a mechanism for that specified in Marc
>> Petit-Huguenin's I-D "Preventing Fragmentation for Client Initiated
>> Connections in the Session Initiation Protocol (SIP)" - but that
>> is not within the baseline Outbound spec and there is no normative
>> binding between those specs either.
>>
>> Regards,
>>
>> Erkki
>
>

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Tue, 2 Jan 2007 13:05:31 -0600

>   support TCP but MAY support UDP too.

Personally, I think that it would be better if Outbound-compliant
UAs (but not Proxies) also had to support UDP.

But I can certainly live with either decision.

>   (or even both) shall be used for that specific deployment.

Correct. A SIP service provider could decide to support TCP or UDP
(or both) as they see fit for their deployment.

Since clients would support both, it would be entirely a service 
provider decision.

>   also mean that TCP-only implementations could not be used for

To me, it's more a question of UDP not working in many cases where
fragmentation may be an issue.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2007 12:31:55 -0600

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, January 02, 2007 1:41 AM

<<snip>> 

>   support TCP but MAY support UDP too.

May support UDP for Outbound, or may support UDP, period? Unless I'm
missing something somewhere, section 18 of RFC-3261 still says that all
SIP elements MUST implement UDP.

---

From: <[email-masked]>
Date: Thu, 4 Jan 2007 11:51:31 +0200

Sorry, I was not clear enough for my formulation.
The scope of my summary was the usage of SIP together
with Outbound, thus I simply meant this:

>May support UDP for Outbound

Regards,

Erkki

---

From: Rathod Subhashchandra <[email-masked]>
Date: Thu, 4 Jan 2007 15:35:09 +0530

Hi All,

I am looking for a tool which shall help in automating third party
software(SIP Stack phone) like automating of buttons click on the soft
phones. It would be a great help if someone provides relevant details.

Thanks !
Rathod.

---

From: Sebastien Tricaud <[email-masked]>
Date: Thu, 04 Jan 2007 11:11:31 +0100

Hello,

For buttons clicks, I guess you can get sounds produced by softphones
and script a player to it :-)

Or, you can use miniua for sip calls scripting. Its documentation is
available there ->
http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/MiniUa

In the hope that help you,

Sebastien.

---

From: Rathod Subhashchandra <[email-masked]>
Date: Thu, 4 Jan 2007 17:39:31 +0530

Hi Sebastien,

I went through this.
Looks very complicated. I am looking a tool like WinRunner. Can you help me
in this?

Thanks !
Rathod.

-----Original Message-----
From: Sebastien Tricaud [mailto:[email-masked]]
Sent: Thursday, January 04, 2007 3:42 PM
To: Rathod Subhashchandra
Cc: [email-masked]
Subject: Re: [Sip] tool for automating soft phone key pad clicking

Hello,

Sebastien.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 4 Jan 2007 10:06:39 -0600

I agree.

> Sent: Thursday, January 04, 2007 3:52 AM
> To: Stucker, Brian (RICH1:AR00); [email-masked]
> Cc: [email-masked]; Audet, Francois (SC100:3055)
> Subject: RE: [Sip] Question about Poll: Proposal relating to 
> keepalive, TCP, and UDP usage in draft-ietf-sip-outbound
> 
> The scope of my summary was the usage of SIP together with 
> Outbound, thus I simply meant this:
>

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Fri, 5 Jan 2007 09:11:06 +0100

Hi,

In a recent prototype I had to emulate processing of a 302 response by a
SIP client by launching a script that actually dials the phone number
received in the Contact header of the 302 on the client's UI. The reason
was obviously that the client did not properly implement the re-dialling
on reception of the 302.

The tool I used is MacroExpress 3 and it worked pretty well.

Hope it is helpful,
/Javier

Rathod Subhashchandra wrote:
> Hi Sebastien,
> 
> I went through this.
> Looks very complicated. I am looking a tool like WinRunner. Can you
> help me in this? 
> 
> Thanks !
> Rathod.
> 
> 
>> software(SIP Stack phone) like automating of buttons click on the
>> soft phones. It would be a great help if someone provides relevant
>> details. 
>> 
>> Thanks !
>> Rathod.
>> 
>> 
>> 
>> 
>> 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: Rathod Subhashchandra <[email-masked]>
Date: Fri, 5 Jan 2007 15:12:44 +0530

Hi Javier,

Thanks lot for this information.
I have installed the Macro Express 3.
Need to play with this tool to know how key strokes can be automated.

My requirement is
1.	I have developed the test automation tool for SIP protocol conformance.
2.	Testing at present with SJPhone. SJPhone needs manual interaction for
accepting/rejecting the call and also to place the MT(Mobile Terminating) to
the Testing tool.
4.	We have close to 300 test cases. Manually accepting/rejecting and placing
call for these many test cases is becoming very difficult job.
Hence, I wanted to automate the SJPhone for
accepting/rejecting/call-placing. I can't write the stub as I don't have
interface document.

At present, I am not sure, whether all above things shall be taken care by
MacroExpress3.

Thanks !
Rathod.

-----Original Message-----
From: Jesus Javier Arauz (MI/EEM)
[mailto:[email-masked]]
Sent: Friday, January 05, 2007 1:41 PM
To: Rathod Subhashchandra; Sebastien Tricaud
Cc: [email-masked]
Subject: RE: [Sip] tool for automating soft phone key pad clicking

Hi,

Hope it is helpful,
/Javier

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 5 Jan 2007 13:29:22 +0100

Hi,

I think that proxies should support both TCP and UDP.

Regards,

Christer 

> Sent: 2. tammikuuta 2007 9:41
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> keepalive, 
> >TCP,and UDP usage in draft-ietf-sip-outbound
> >
> >
> >>>> example, and they will always fragment. And I might add 
> that many 
> >>>> very popular NAT/routers don't support UDP fragmentation.
> >>>
> >> Please remember that the proposal that you do not agree 
> with was like 
> >> this:
> >>
> >>>> You mean a UA will open two connections, one for UDP and another 
> >>>> for TCP? I fail to see why on earth anybody would do 
> this instead 
> >>>> of just using a single TCP
> >connection.
> >>>
> >> available, there is no way for the proxy to get the UA to 
> open such 
> >> connection or for the proxy itself open such a TCP 
> connection towards 
> >> the UA via the NAT when a large message arrives destined 
> to the UA. 
> >> So if the UA does not keep the TCP connection open all the 
> time, it 
> >> has to live with the limitation of not being able to receive SIP 
> >> requests bigger than MTU if the NAT discards fragmented 
> UDP packets.
> >>
> >> Connections in the Session Initiation Protocol (SIP)" - 
> but that is 
> >> not within the baseline Outbound spec and there is no normative 
> [email-masked] for questions on current sip