headers
Paul Kyzivat | 2 Jan 2007 19:20
Picon
Favicon

Re: Enable special treatment for 18X response

Just to elaborate on what Dale says, the SIP responses aren't there for 
the purpose of mapping to QSIG - they mean what they mean. If the 
response has some significance on the ISDN side then it seems like it 
ought to be mapped. (If the gateway was replaced with a more 
conventional UAC, would you want *it* to ignore the meaning of the 
response as well?)

For instance, if the response is 180 Ringing, are you asking that the 
gateway not indicate the alerting status via QSIG?

	Paul

Dale.Worley <at> comcast.net wrote:
>    From: "Jayesh Sangpal" <jsangpal <at> rediffmail.com>
> 
>    Hi Experts,In my scenario, Caller is&nbsp; ISDN-SIP gateway,Callee
>    receieves INVITE request and responds with 18X response. Callee TU
>    want to specify that 18X should not be mapped to equivalent QSIG
>    message at Caller TU.Is there any mechanism in SIP (extention/
>    Header/ Header-param) by which UAS can tell UAC to treat the 18X
>    specially&nbsp; ? (not to map the 18X to ISDN in my case). Thus
>    Callee would check this mechanism and then make decisionThe
>    mechanism could be application specific. (as TU is involvedin
>    sending 18X)Thanks in Advance ,Jayesh
> 
> Perhaps have the callee use a custom 1xx response.  Any 1xx other than
> 100 is functionally equivalent to a standard SIP UAC, it carries a
> to-tag and establishes an early dialog.  But if it's not one that has
> a defined QSIG mapping, it shouldn't cause the UAC to generate an ISDN
> status.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 2 Jan 2007 19:41
Picon
Favicon

Re: Regarding RFC 3262


P Vinod wrote:
> Hi,
> 
> In RFC 3262, the following snippet is found:
> 
> <Quote>
> The PRACK request plays the same role as ACK, but for provisional responses.
> There is an important difference, however. PRACK is a normal SIP message,
> like BYE. As such, its own reliability is ensured hop-by-hop through each
> stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response.
> If this were not the case, the PRACK message could not traverse proxy
> servers compliant to RFC 2543 [4].
> </Quote>
> 
> Could any of the members explain about the last statement:
> If this were not the case, the PRACK message could not traverse proxy
> servers compliant to RFC 2543 [4].
> 
> thanks
> PV

PV,

In both 2543 and 3261 the only message that doesn't get a response is 
ACK. In both, an unknown message is treated as a normal message and the 
beginning of a non-invite transaction. A proxy that doesn't understand 
PRACK treats it as a standard non-invite transaction, and this works 
because it gets a response.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rohit Sonalkar | 2 Jan 2007 19:54

Question about modifying a session - RFC 3264

Hello,

I have a question about Section 8 of RFC 3264, Modifying a Session. This
section clearly states that:

1. If new offer SDP is different from previous SDP, session version must
be incremented 
2. It new offer SDP has same version as previous SDP, new SDP must be
identical to previous SDP

It does not say whether the receiver should treat as invalid the
following combinations in the new offered SDP:

1. Different SDP, same version number
2. Same SDP, different version number

How should the receiver treat the new offered SDP in either of these two
cases, how can it 'reject' the offer as invalid?

Thanks
Rohit
Permalink | Reply | 2 comments |
headers
Ramesh | 2 Jan 2007 20:34
Picon

Use of REFER in 3pcc

Hi,
   I have come across a Draft that uses REFER to accomplish the 33PCC calls
instead of the INVITE method as stated by the RFC 3725. Can somebody
substantiate the reasoning behind not taking the REFER path. I am pretty
sure there is some very valid reason I just want to get educated on the
reason as I could not find too many threads on this subject.

--

-- 
cheers
ramesh
Permalink | Reply | 4 comments |
headers
Gary Cote | 2 Jan 2007 22:00
Picon

Re: Question about modifying a session - RFC 3264

On 1/2/07, Rohit Sonalkar <rohit <at> ipunity.com> wrote:

> It does not say whether the receiver should treat as invalid the
> following combinations in the new offered SDP:
>
> 1. Different SDP, same version number

The spec seems clear on this one, as you yourself stated. It violates
condition #1 in your message. So, I'm confused ... why do you suggest
that it's unclear?

As for the appropriate way to reject the offer, I would suggest
sending a 400 Bad Request response. The reason phrase should clarify
the nature of the syntax error.

>
> 2. Same SDP, different version number
>

Granted, this one is a little less clear, but a precise reading would
seem to indicate that this is not an error condition. I don't see
where it explicitly disallows incrementing the session version, but
keeping the same SDP. I'm sure someone will correct me if I've missed
a key phrase somewhere.

I would expect the answerer to dutifully construct an equivalent answer.

Hope that helps.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 2 Jan 2007 22:01
Picon
Favicon

Re: Question about modifying a session - RFC 3264

We don't usually specify behavior in no-compliant cases. You are free to 
do as you wish - fail the request or cope.

IMO the purpose of the session version is to permit an optimization when 
nothing has changed. If you don't do the optimization then there is 
little reason to validate the version, and if you do the optimization 
then checking the version will degrade the optimization to some extent, 
though perhaps not as much as not doing the optimization.

Does anybody check this?

	Paul

Rohit Sonalkar wrote:
> Hello,
> 
> I have a question about Section 8 of RFC 3264, Modifying a Session. This
> section clearly states that:
>  
> 1. If new offer SDP is different from previous SDP, session version must
> be incremented 
> 2. It new offer SDP has same version as previous SDP, new SDP must be
> identical to previous SDP
> 
> It does not say whether the receiver should treat as invalid the
> following combinations in the new offered SDP:
> 
> 1. Different SDP, same version number
> 2. Same SDP, different version number
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kyzivat | 2 Jan 2007 22:05
Picon
Favicon

Re: Use of REFER in 3pcc


Ramesh wrote:
> Hi,
>    I have come across a Draft that uses REFER to accomplish the 33PCC calls
> instead of the INVITE method as stated by the RFC 3725. Can somebody
> substantiate the reasoning behind not taking the REFER path. I am pretty
> sure there is some very valid reason I just want to get educated on the
> reason as I could not find too many threads on this subject.

Not all UAs support REFER. If you want your 3pcc implementation to work 
with as many UAs as possible the way using INVITE may be better.

	Paul
Permalink | Reply | 3 comments |
headers
Alan Johnston | 2 Jan 2007 23:12

Re: Use of REFER in 3pcc

However, it has been pointed out recently that RFC 3725 does not work 
with dynamic payloads in the SDP.  With many current and all future 
codecs using dynamic payloads, this could be a much greater 
interoperability issue than support of REFER.

As an aside, a number of us plan a new effort to get this draft on 
remote call control using REFER adopted as a working group item so it 
can progress to RFC.

      http://www.ietf.org/internet-drafts/draft-mahy-sip-remote-cc-04.txt

Thanks,
Alan

Paul Kyzivat wrote:
> Ramesh wrote:
>   
>> Hi,
>>    I have come across a Draft that uses REFER to accomplish the 33PCC calls
>> instead of the INVITE method as stated by the RFC 3725. Can somebody
>> substantiate the reasoning behind not taking the REFER path. I am pretty
>> sure there is some very valid reason I just want to get educated on the
>> reason as I could not find too many threads on this subject.
>>     
>
> Not all UAs support REFER. If you want your 3pcc implementation to work 
> with as many UAs as possible the way using INVITE may be better.
>
> 	Paul
> _______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Xavier Marjou | 3 Jan 2007 09:23
Picon

Re: Use of REFER in 3pcc

I agree that a REFER message is better than a B2BUA for 3rd party
call-control. For example, a B2BUA can not guess the SIP methods (of
Allow header) and SIP option-tags (of Supported & Required headers) of
the 2nd party when sending the first INVITE to the 1st party.

> Not all UAs support REFER.

Unfortunately, this is especially true in SIP-PSTN gateways.
Permalink | Reply | 0 comments |
headers
Naveen Kak | 3 Jan 2007 11:24
Favicon

Invite-200OK Transaction


Hi,
What is the reason for Invite-200 OK being one transaction and Ack being
a separate transaction. But for non-200OK final response its just one
transaction(including the Ack).

Thanks
Naveen 
-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of malathi
kamath
Sent: Friday, December 29, 2006 9:47 AM
To: sip-implementors <at> cs.columbia.edu
Subject: [Sip-implementors] About route header and target set

Hi all,
>From RFC 3261 i could not understand how postprocessing is done if
route
header is present in the request.
Is there any neccessity to find target set (as given in sec.16.5) if
route
header is present?

thanks
malathi
_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
(Continue reading)

Permalink | Reply | 0 comments |

Gmane