-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 9:22 PM
To: [email protected]
Subject: Sip-implementors Digest, Vol 43, Issue 23
Send Sip-implementors mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip-implementors digest..."
Today's Topics:
1. Re: two ACKs for one 200 ok? (Manish Jain)
2. Re: [B2BUA] Call Flow Inquiry (Sumin Seo)
3. Re: [B2BUA] Call Flow Inquiry (Sumin Seo)
4. Re: [B2BUA] Call Flow Inquiry (Gary Cote)
5. Re: [B2BUA] Call Flow Inquiry (Gary Cote)
6. SIP stack for IMS (Gaurav Kansal)
7. branch tag in Via header (Dave Stuart)
8. Re: [Sip] RFC3263 - Server Usage query (Scott Lawrence)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Oct 2006 10:12:42 -0700 (PDT)
From: Manish Jain <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] two ACKs for one 200 ok?
To: Achint Aggarwal <[EMAIL PROTECTED]>,
asura_hzk <[EMAIL PROTECTED]>
Cc: [email protected],
[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
Hi Asura,
RFC does not allows such scenerio. In some standard
implementation of stack+transaction unit, it will
leads to transaction failure.
Best Regards,
Manish Jain
--- Achint Aggarwal
<[EMAIL PROTECTED]> wrote:
> Hi Asura!
>
> I don't think this is a scenario compliant with
> 3261.
> It is because for the first 200OK that was sent for
> the INVITE from UAS
> carrying sdp(an offer) information,UAC must generate
> the answer to that
> offer in the first ACK as expected by a SIP entity
> we call UAS.
>
> If answer sdp is sent in the 2nd ACK for the first
> 200OK then i guess it
> leads to incomplete offer-answer model and then UAS
> may behave differently
> to the answer in the 2nd ACK,rejecting it perhaps.
> Regards
> Achint
>
>
>
> asura_hzk <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 10/09/2006 02:41 PM
>
>
> To
> [email protected]
> cc
>
> Subject
> [Sip-implementors] two ACKs for one 200 ok?
>
>
>
>
>
>
>
> hello,friends ,I met a scenario like this
>
> Sip server Sip Client
> INVITE(without SDP)
> ------------------->
> 200 OK(with SDP)
> <------------------
> ACK(without SDP)
> ------------------->
> ACK(with SDP)
> ------------------->
>
> The first ACK is just for stopping the
> retransmitting "200 ok",I thought,
> Because the second ACK should be received after the
> remote client accepted
> the
> call.The server is not developped by ourselves,So I
> dont know whether this
>
> implementation complies to RFC?
>
> Waiting for your instruction,Thank you!
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
>
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
> *********************** FSS- Confidential
> ***********************
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
>
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
------------------------------
Message: 2
Date: Wed, 11 Oct 2006 11:05:21 -0700
From: "Sumin Seo" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] [B2BUA] Call Flow Inquiry
To: "Gary Cote" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thanks for your replay, guys.
Markus,
4xx is just one of re-INVITE failure examples.
Gary,
I have questions on your answer.
1. Do you mean that UA can't initate INVITE client transaction if
there is uncompleted or uncomfimed INVITE server transaction?
For example, if there is uncompleted or uncomfimed INVITE server
transaction, UA can't initiate re-INVITE for session timer request?
2. Even though B2B has INVITE server transaction related with UA1,
there is no pending transaction between B2B and UA2. What happen in
UA2 if B2B sends 491 although all previous INVITE transactions between
B2B and UA2 completed?
Thank you in advance.
Sumin.
On 10/11/06, Gary Cote <[EMAIL PROTECTED]> wrote:
> On 10/10/06, Sumin Seo <[EMAIL PROTECTED]> wrote:
> >
> > UA1 --------------- B2B --------------- UA2
> >
> > After session refreshment, UA1 sends re-INVITE and B2B responses 4XX
> > error to UA1.
>
> You probably already know this, but it might be worth repeating. The B2BUA
> implements two dialogs - one between UA1 and B2B, and the other between
> B2B and UA2. The B2BUA must be sure that each of the two dialogs correctly
> conforms to the rules of the protocol.
>
> A B2BUA is simple in concept, but the "unusual" cases introduce
complexity.
> You've uncovered just such a case: one of the UA sends a re-INVITE. It
fails
> for some reason. While that's going on, the other UA sends a re-INVITE.
>
> >
> > While B2B waits for ACK from UA1, can B2B send re-INVITE to UA1
> > if UA2 sends re-INVITE to B2B?
> >
>
> No ... B2B cannot send a re-INVITE to UA1 until the first invite server
> transaction reaches the confirmed or terminated state (see RFC 3261,
> Section 14.1). Your transaction is still in the completed state.
>
> >
> > If B2B doesn't want to process re-INVITE from UA2 before previous
> > re-INVITE transaction between UA1 and B2B completes, what kind of
> > final response should B2B send to UA2 as final response?
> >
>
> You might consider a 491 Request Pending response.
>
> Or, perhaps even better ...
>
> B2B could delay sending the re-INVITE from UA2 until it receives the ACK
> from UA1. B2B could start a timer. If it receives the ACK before the timer
> expires, then simply forward the re-INVITE on. If the timer expires, then
> send a 491 response to UA2.
>
> Hope that helps.
>
> --
> Gary Cote
> Award Solutions, Inc.
> www.awardsolutions.com
>
------------------------------
Message: 3
Date: Wed, 11 Oct 2006 12:26:33 -0700
From: "Sumin Seo" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] [B2BUA] Call Flow Inquiry
To: "Gary Cote" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thanks Gary.
Here is example call flow.
B2B
UA1 <------------> UAS|UAC <--------------> UA2
|----------------- session established ------------|
| re-INVITE | |
|----------------------------->| |
| error response | |
|<-----------------------------| |
| | re-INVITE |
| |<-------------------------- |
As you see, there is pending request beween UA1 and UAS of B2B, but in
view of UA2, there is no pending request between UAC of B2B and UA2 .
It might be okay if B2B sends 491/500 to UA2 and then UA2 responses to
the final response with ACK.
But I think final error response should explain why the request was
rejected or failed. In view of UA2, if UA2 receives 491 from B2B, I
think UA2 doesn't know why B2B sent 491 although there is no pending
request in the dialog between UA2 and B2B.
As you said, I think 500 with Retry-After would be better than 491 in this
case.
Thanks in advance.
Sumin.
On 10/11/06, Gary Cote <[EMAIL PROTECTED]> wrote:
>
>
> On 10/11/06, Sumin Seo <[EMAIL PROTECTED]> wrote:
> > 1. Do you mean that UA can't initate INVITE client transaction if
> > there is uncompleted or uncomfimed INVITE server transaction?
> > For example, if there is uncompleted or uncomfimed INVITE server
> > transaction, UA can't initiate re-INVITE for session timer request?
>
> That's correct. Have you read RFC 3261, Section 14.1? It's pretty clear.
>
> > 2. Even though B2B has INVITE server transaction related with UA1,
> > there is no pending transaction between B2B and UA2. What happen in
> > UA2 if B2B sends 491 although all previous INVITE transactions between
> > B2B and UA2 completed?
>
> Again, RFC 3261, Section 14.1 is pretty clear about how the UAS should
react
> to the 491 Request Pending response. Which part didn't you understand?
>
> I guess an alternative to the 491 Request Pending response would be a 500
> Internal Server Error response, with a Retry-After header telling the UA
> when to try the re-INVITE again.
>
> - g
>
>
------------------------------
Message: 4
Date: Wed, 11 Oct 2006 13:34:34 -0500
From: "Gary Cote" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] [B2BUA] Call Flow Inquiry
To: "Sumin Seo" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/11/06, Sumin Seo <[EMAIL PROTECTED]> wrote:
>
> 1. Do you mean that UA can't initate INVITE client transaction if
> there is uncompleted or uncomfimed INVITE server transaction?
> For example, if there is uncompleted or uncomfimed INVITE server
> transaction, UA can't initiate re-INVITE for session timer request?
That's correct. Have you read RFC 3261, Section 14.1? It's pretty clear.
2. Even though B2B has INVITE server transaction related with UA1,
> there is no pending transaction between B2B and UA2. What happen in
> UA2 if B2B sends 491 although all previous INVITE transactions between
> B2B and UA2 completed?
Again, RFC 3261, Section 14.1 is pretty clear about how the UAS should react
to the 491 Request Pending response. Which part didn't you understand?
I guess an alternative to the 491 Request Pending response would be a 500
Internal Server Error response, with a Retry-After header telling the UA
when to try the re-INVITE again.
- g
------------------------------
Message: 5
Date: Wed, 11 Oct 2006 18:31:31 -0500
From: "Gary Cote" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] [B2BUA] Call Flow Inquiry
To: "Sumin Seo" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Using your diagram below as a reference:
Let D1 be the dialog between UA1 and B2B.
Let D1.T1 be the re-INVITE transaction between UA1 and B2B.
Let D2 be the dialog between B2B and UA2.
Let D2.T1 be the re-INVITE transaction between UA2 and B2B.
In a previous email, I suggested that B2B might send a 491 Request
Pending in response to D2.T1.
It is true, as you suggest in your most recent email, that the 491 is
intended to resolve a race condition between two re-INVITE
transactions within the same dialog. So, my suggestion takes some
creative license with respect to the semantics of the response code.
But consider the following:
a) The 491 shall be sent by the UAS transaction user (TU) layer.
b) In this case, the TU is the B2BUA logic.
c) The purpose of a B2BUA is to bind the two independent dialogs (D1 &
D2) together in some way that makes sense to the application being
implemented.
d) The B2BUA logic recognizes the conflict between D2.T1 and D1.T1
(otherwise you wouldn't have asked your original question).
IMO, it's reasonable for B2B to tie D2.T1 and D1.T1 together. The more
significant part of my original suggestion was to start a timer. If
B2B receives the ACK and D1.T1 completes, then B2B can continue
processing D2.T1. If the timer expires before it gets the ACK, then
B2B sends an error response D2.T1.
The error response could be a 491 Request Pending. It is, perhaps, a
creative use of the response code because, as we said, the pending
request is actually within D1. But UA2 doesn't need to know that and I
don't see that it violates any protocol rules or causes any problems
(again, the list can correct me if I'm wrong). So it sounds reasonable
to me.
Or, the error response could be a 500 Server Internal Error. You don't
know when or if you're going to get the ACK, though, so any value for
the Retry-After header would have to be a blind guess.
I don't think the choice of error code is that significant. I'm sure
you'll figure something out.
--
Gary Cote
Award Solutions, Inc.
www.awardsolutions.com
On 10/11/06, Sumin Seo <[EMAIL PROTECTED]> wrote:
>
> B2B
> UA1 <------------> UAS|UAC <--------------> UA2
> |----------------- session established ------------|
> | re-INVITE | |
> |----------------------------->| |
> | error response | |
> |<-----------------------------| |
> | | re-INVITE |
> | |<-------------------------- |
>
> As you see, there is pending request beween UA1 and UAS of B2B, but in
> view of UA2, there is no pending request between UAC of B2B and UA2 .
------------------------------
Message: 6
Date: Thu, 12 Oct 2006 08:45:01 +0530
From: "Gaurav Kansal" <[EMAIL PROTECTED]>
Subject: [Sip-implementors] SIP stack for IMS
To: <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Hello
I am in the process of evaluating a SIP stack for IMS enhancements (for
CSCF). I compared SIPx, SER and reciprocate stacks for CSCF development.
Resiprocate:
Pros:
1. Slightly less distributed architecture than SIPx
2. Can run as registrar/proxy/redirect server
3. TLS support for Security
4. Support for NAT
5. Web based management interface
6. IPv6 support
7. Maximum standards compliance
Other notes:
1. Developers are mostly RFC authors also, so implementation is full
and true reference implementation
2. SIP foundry says that resiprocate is most advanced and interoperable
open source SIP stack
3. Many IMS headers are supported in latest release 1.0
SIPx:
Pros:
1. Complete SIP based IP-PBX solution
2. Distributed architecture
3. Can run as registrar/proxy/redirect server
4. TLS support for Security
5. Support for NAT
6. Web based management interface
Cons:
1. Missing IPv6 support
2. Large footprint
SER:
Pros:
1. Can run as registrar/proxy/redirect server
2. TLS support for Security
3. Support for NAT
4. Web based management interface
5. IPv6 support
Cons:
1. GPL license
I have following queries:
1. Can somebody point out if anything out of above is not correct or if
people can add more?
2. Which stack is more actively being used for IMS enhancements?
3. Which stack is better suited for IMS compliance as per 3GPP
standards?
Regards,
Gaurav Kansal
------------------------------
Message: 7
Date: Thu, 12 Oct 2006 10:49:28 -0400
From: Dave Stuart <[EMAIL PROTECTED]>
Subject: [Sip-implementors] branch tag in Via header
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain
Hello All,
The spec seems to indicate this but I want to clarify what is "best
practice".
Is the branch tag in the Via header case-sensitive, or case-insensitive?
Dave
--
David Stuart, FirstHand Technologies (formerly SIPquest)
Email: dstuart (at) firsthandtech (dot) com
Phone: (613) 254-8886 x234 Web: http://www.firsthandtech.com/
Address: 300 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
------------------------------
Message: 8
Date: Thu, 12 Oct 2006 11:47:48 -0400
From: Scott Lawrence <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] [Sip] RFC3263 - Server Usage query
To: "Sachin Danait (sdanait)" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8
On Wed, 2006-10-11 at 08:34 -0700, Sachin Danait (sdanait) wrote:
[reply limited to sip-implemntors]
> I have a question regarding Section 5 (Server Usage) of RFC3263 that I
> am requesting your opinion on.
> IMHO, there appears to be an issue with server-side Via header
> processing rules as currently specified in RFC 3263, when a Via header
> of the received request sent-by address field has an SRV name (a port
> is not specified on the header) and the SRV name resolves to
> non-default SIP ports.
> Section 5 of RFC3263 references section 18.2.2 of RFC3261, and states
> that for unreliable transports, the initial response transmission sent
> by a UAS should be attempted towards the source address of the
> received request and the default destination port (5060) if none is
> specified in the Via header. If this initial response encounters a
> failure and there wasn?t any port specified in the Via, the UAS should
> resolve the domain name in the sent-by field using SRV procedures, and
> the response should be sent to the address and port selected based on
> that SRV query.
> My question is regarding the first step of the above response
> processing logic.
> Since SRV lookups are performed on a domain-name only when no port is
> specified, this obligates the sender of a request to not encode a port
> in its Via header if that sender wishes to be reachable using SRV
> resolution. Consequently, this appears to imply that the sender needs
> to be listening for responses on the default SIP port in addition to
> any of the ports resolved from the SRV query, since the first
> transmission of any incoming response will always be directed towards
> the default port as per section 18.2.2 of RFC3261.
I don't think so. If the name in the Via is resolvable as an SRV name,
then the SRV record _does_ specify the port, so section 18.2.2 does not
apply. Only if the name in the Via must be resolved as a host address
lookup without SRV should the port be considered unspecified and be sent
to the default well known port.
--
Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:[EMAIL PROTECTED]
sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX
Chief Architect - Pingtel Corp. http://www.pingtel.com/
------------------------------
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
End of Sip-implementors Digest, Vol 43, Issue 23
************************************************
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-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
