Re: [Sip-implementors] deregistration: Contact in 200 OK?

Option (a - no Contacts) is the normal practice. Option (b - Contacts w/expires=0) is legal, but might confuse some User Agent implementations. A REGISTER which removes the contacts removes the bindings in the registrar. The 200-OK response has a Contact for each binding. If all the bindings hav

Re: [Sip-implementors] proxy and route header

inline - Original Message - From: "Paul Kyzivat" <[EMAIL PROTECTED]> To: "Ivar" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, April 24, 2007 5:23 PM Subject: Re: [Sip-implementors] proxy and route header > > > Ivar wrote: >> Hmm, i tought i described well. >> >> But ok, request-URI it the one

Re: [Sip-implementors] Basic Authentication

How about 403 Forbidden? - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Wednesday, April 11, 2007 5:45 PM Subject: Re: [Sip-implementors] Basic Authentication > From: <[EMAIL PROTECTED]> > > 400 Bad Request might not be appropriate as "Basic" is syntactically > correct.

Re: [Sip-implementors] SIP Contact header

inline - Original Message - From: "Stephen Paterson" <[EMAIL PROTECTED]> > Hi all, > > What happens if the 1xx does not contain a contact header? According to > RFC 3261, this is optional for 1xx response (see table 2, page 162), it > is only mandatory for 2xx response. Does 3262 update

Re: [Sip-implementors] SIP Contact header

> >> 2) How about PRACK or UPDATE request which is sent from UAC >>to UAS before the dialog is established (i.e.: 200 ok to >>INVITE is not sent by UAS yet)? (I assume same as the ACK >>for non-200 response). >> > > When you send PRACK, it means you have received a reliable 1xx response

Re: [Sip-implementors] Importance of To-Tag in 200 OK of Register

The lack of a to-tag in a response does not make it invalid. Although RFC 3261 requires a to-tag, RFC 2543 did not require a to-tag be added to the response unless the original request had multiple Via headers. Section 6.37 of RFC 2543 says: The UAS or redirect server copies the To header f

Re: [Sip-implementors] 200 OK

The top Via (line 15) in the response does not match the top Via in the request that was sent. The 'sent-by' is different: 127.0.0.1:5060 vs. 127.0.0.1:5061 cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED]

Re: [Sip-implementors] How to create a binding if Contact header is notthere in the REGISTER request?

A REGISTER request that contains no "address binding" (i.e. no Contact header values) does not create any bindings. It is used to query the registrar for the current set of bindings for the address-of-record in the To header. The response will contain Contact header(s) with the current address

Re: [Sip-implementors] Target refresh requests

In general, dialog initiating requests and target refresh (in-dialog) requests (and non-failure end-to-end responses) always carry the remote target. There is no special case for in-dialog requests. The rules for whether or not a Contact header is included do not depend on whether the request i

Re: [Sip-implementors] changing IP address for sub register messages

Again, the fact that the Call-Id is the same does not cause the registrar to remove a binding. If there are two REGISTER requests from the same UA but they have different contacts (say address A and address B), then there will be two bindings and an INVITE would be forked to both contacts (A and

Re: [Sip-implementors] changing IP address for sub register messages

inline - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Saturday, February 24, 2007 8:34 AM Subject: Re: [Sip-implementors] changing IP address for sub register messages > From: "erol turac" <[EMAIL PROTECTED]> > > If an endpoint sends initial invites with ip address A, and

Re: [Sip-implementors] branch tag in Via header

All tokens should be compared case-insensitive. Quoting the Bugzilla report: >From Robert Sparks 2006-03-26 23:02 --- To restate: The branch parameter is ALWAYS compared case insensitive. There are no exceptions to this rule. It is unfortunate that we chose a mixed-case magic cookie for th

Re: [Sip-implementors] A query as to know whether an INFO message canget forked

Since INFO is defined as an in-dialog request (RFC 2976 still called it a call leg, but its a dialog), the request should not be forked. In a dialog there are only two UAs at either end. Any forked in-dialog request would receive a 481 response from the UAS's that are not part of that dialog.

Re: [Sip-implementors] query regarding parallel forking

- Original Message - From: "Alf Salte" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]> Sent: Thursday, September 28, 2006 7:32 AM Subject: Re: [Sip-implementors] query regarding parallel forking > On Thu, 2006-09-28 at 07:09 -0400, Bo

Re: [Sip-implementors] query regarding parallel forking

inline. - Original Message - From: "Alf Salte" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; Sent: Thursday, September 28, 2006 5:45 AM Subject: Re: [Sip-implementors] query regarding parallel forking > This is not specified in any RFC. It is up to the proxy how

Re: [Sip-implementors] Repeat Bye Request with Wrong Credentials

If the UAC continues to send the request will invalid credentials, after a few failures you could respond with 403 Forbidden and hopefully that will stop the UA from sending additional BYEs. I have seen this in some implementations. For example, a "three strikes and your out" approach. UAC

Re: [Sip-implementors] Out of dialog BYE

Generally, the proxy should forward the request. A typical proxy does not keep dialog state, so there would be no way for the proxy to know that it was an 'out-of-dialog'. One of the UAs might be RFC 2543 compliant and RFC 2543 did not require a tag in the From/To header in all cases. Even if t

Re: [Sip-implementors] Session, Dialog in RFC

I stand corrected. A "session" is the set of media streams. I guess what I was using the term session for can best be described as the collection of dialogs created by a single dialog creating request. I don't know if we have a term for that. We call it a SIP session (as opposed to the media ses

Re: [Sip-implementors] Session, Dialog in RFC

> >> Is a session containing serveral dialogs > > No, that's not possible! An INVITE session can only have one > underlying dialog. But, a dialog may have several sessions (for > example, one INVITE session, and multiple event subscription > "sessions"). > "session" is not the correct term here.

Re: [Sip-implementors] draft-ietf-sip-outbound-04 - TCP keepalive

venue Burlington, MA 01803 [EMAIL PROTECTED] - Original Message - From: "Attila Sipos" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]>; Sent: Friday, July 28, 2006 8:57 AM Subject: RE: [Sip-implementors] draft-ietf-sip-outbound-04 - TCP keep

Re: [Sip-implementors] draft-ietf-sip-outbound-04 - TCP keepalive

If the UA cannot use the TCP keepalive, it uses the STUN keepalive defined in outbound-04. See section 4.4. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED] - Original Message - From: "Attila Sipos" <[

Re: [Sip-implementors] query regarding request URI of ACK

The Request-URI in an ACK for a success response (2xx) is the Contact from the 2xx response. The Request-URI in an ACK for an error response (3xx,4xx,5xx,6xx) must be the same as the INVITE request. You missed the first paragraph in 17.1.1.3 that talks about ACK for 2xx responses: This sec

Re: [Sip-implementors] Offer in a 200OK for Invite transaction.

No, a second offer cannot be sent in the 200OK. Only one offer/answer exchange is permitted per transaction. The UAS should send the 200-OK either w/o SDP or the same SDP as the 18x. Then is can send an UPDATE or a reINVITE to propose a new offer. cheers, (-:bob Robert F. Penfield Chief Softwa

Re: [Sip-implementors] SIP URI header

In addition to the normative text forbidding escaped characters, there is also Table 1 on page 151/152 of RFC 3261. Escaped characters are only allowed in "header" parameters of a URI. However, "header" parameters are not allowed in a Request-URI according to Table 1. The normative text and ta

Re: [Sip-implementors] From-tag on Registration attempt

The from-tag SHOULD be the same. The example in RFC 3665, which is not 'normative' (its just examples, not a protocol specification), is not correct. According to RFC 3261 section 8.1.3.5 (Processing 4xx Responses): In all of the above cases, the request is retried by creating a new reque

Re: [Sip-implementors] From-tag on Registration attempt

5 currently shows the tag changing instead of following > the rfc3261 section 8.1.3.5 SHOULD text. Thus RFC3665 potentially should > be corrected via errata or bugzilla. > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf

Re: [Sip-implementors] From-tag on Registration attempt

It is referring to the entire From header, including the tag. The only difference in the request should be the CSeq (increased by 1), and the addition of credentials (WWW-Authenticate or Proxy-Authenticate). cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third A

Re: [Sip-implementors] [Sip] Header Encoding for WWW-Authenticate

Questions like this really belong on the Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors If the line following the CRLF begins with whitespace, that line is a continuation of the same header. Section 7.3 of RFC 3261

Re: [Sip-implementors] question on the behavior of 487 message.

Non-success final responses (3-6xx) and the ACK to those responses are hop-by-hop. Regardless of whether or not the proxy forwards the non-success final response upstream toward the UAC, it MUST always send an ACK. RFC 3261, section 16.7 (page 111) says: 3-6xx responses are delivered hop-by

Re: [Sip-implementors] question on the behavior of 487 message.

Error responses (3xx,4xx,5xx, and 6xx) are hop-by-hop. The proxy must always send the ACK to an error response. Only the ACK for a success (2xx) response is sent end-to-end. A proxy is suppose to send only one error response back to the UAC(A). Also, the proxy does not forward an ACK to an error

Re: [Sip-implementors] [Sip] Stateless proxy and reliable transport

Questions like this really belong on the Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors There is rule against a stateless proxy changing the transport for exactly this reason. In section 16.1 of RFC 3261 it says "R

Re: [Sip-implementors] Requests within a Dialog

- From: "Sreejesh" <[EMAIL PROTECTED]> To: "Sip-Implementors" Cc: "Bob Penfield" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Gupta, Ajay" <[EMAIL PROTECTED]> Sent: Friday, April 07, 2006 10:08 AM Subject: Re: [Sip-implement

Re: [Sip-implementors] Requests within a Dialog

g the guidelines of Section 8.1.1.5." The CSeq MUST be incremented by 1. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED] - Original Message - From: "Uttam Kumar Sarkar" <[EMAIL PROTECT

Re: [Sip-implementors] Requests within a Dialog

A dialog is identified by the Call-ID, from-tag, and to-tag. Any request within an existing dialog must include the to-tag. The CSeq should increment by 1 for each new request. See section 12.2 of RFC 3261. http://www.ietf.org/rfc/rfc3261.txt cheers, (-:bob Robert F. Penfield Chief Software A

Re: [Sip-implementors] Forking: early dialog termination

It is not necessary for a UAC to cleanup other early dialogs (i.e. send BYEs) when it receives a 2xx. The forking proxy would have issued a CANCEL to all the other UASs in attempt to prevent them from completing the INVITE. Those UAS's would send a 487 response to the INVITE which would stop at

Re: [Sip-implementors] Transport layer changes transport.

The transaction layer would not start Timer A until it was told by the transport layer that the message was sent on UDP. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED] - Original Message - From: "Marku

Re: [Sip-implementors] querry abt number of messages per packet.

inline - Original Message - From: "Ajay Kulkarni" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 04, 2006 1:51 AM Subject: [Sip-implementors] querry abt number of messages per packet. > Hi all... > > i have following doubts > > 1) can single UDP packet have more than one SIP messages? No

Re: [Sip-implementors] Forking: early dialog termination

inline - Original Message - From: "Sigrid Thijs" <[EMAIL PROTECTED]> > Hi, > > I'm sorry if this has been asked before, but I haven't found a real > answer to this question. > According to RFC 3261: > > If the forwarded response was a final response, the proxy MUST > generate a CANCEL

Re: [Sip-implementors] Forking with 18x responses

The behavior of these gateways is wrong. All 1xx, and 2xx messages from a UAS for the a given INVITE (i.e. assuming its the same call) must have the same to-tag because they are for a single dialog. The gateway vendor should fix this immediately. The UAC can only assume that they are separate d

Re: [Sip-implementors] media session

RFC 3264 says: Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of c

Re: [Sip-implementors] CANCEL request in the INVITE initiated Dialog

CANCEL SHOULD NOT be > sent, as it is an effective no-op, since CANCEL has no effect on > requests that have already generated a final response. > vimal: this means that cancel can be sent only for early dialog. if final > response is already received no point sending cancel. > >

Re: [Sip-implementors] CANCEL request in the INVITE initiated Dialog

The CANCEL MUST have the same to-tag as the INVITE it is cancelling. If the INVITE had a to-tag, the CANCEL MUST have the same to-tag. If the INVITE did not have a to-tag, the CANCEL MUST NOT have a to-tag. Section 9.1 of RFC 3261 is very clear on this: The Request-URI, Call-ID, To, the numer

Re: [Sip-implementors] example of uri header in RFC 3261

The characters that are not allowed in URI headers need to be escaped. sip:[EMAIL PROTECTED]&Call-Info= would be encoded as: sip:[EMAIL PROTECTED]&Call-Info=%3Chttp://www.foo.com%3E cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue

[Sip-implementors] Contact header in 4xx,5xx,6xx responses

RFC 3261 section 13.2.2.3 says 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. But table 2 indicates it is only legal in a 485 response. Header field where proxy ACK B

Re: [Sip-implementors] Max-Forwards in CANCEL

Yes. All CANCEL requests must contain a Max-Forwards header. CANCEL may be responded to hop-by-hop, but each downstream proxy will forward the CANCEL on to any and all outstanding branches (client transactions). Therefore, the Max-Forwards is still needed in case it gets into a loop within the pro

Re: [Sip-implementors] basic doubt in interpretation of RFC section

inline. - Original Message - From: "Revathi K" <[EMAIL PROTECTED]> > Hi, > I have some basic doubts about the To-tag processing by proxy. > When will a proxy ever need to insert a To-tag in a response? > > Section 16.7 of the RFC says that: > >3-6xx responses are delivered hop-by-hop

Re: [Sip-implementors] SDP query

It is OK that the answer uses a different payload. However, the Answer in you example is not correct because it includes payload 96, but no "rtpmap". Assuming the answerer wants payload 97 for telephone-event, it should look like this: Answer m: audio 8000 RTP/AVP 18 0 97 rtpmap: 18 G729/8000 rtpm

Re: [Sip-implementors] clarification of RFC3261 text

No, the UAC should not send a BYE on the remaining early dialogs. If the request was forked, the proxy that forked the request would have sent CANCEL to the remaining branches upon receiving the 200-OK. Normally, those branches would return 487 which the proxy would not pass back to the UAC. The UA

Re: [Sip-implementors] keep alive with NAT in SIP

The current draft, draft-ietf-sip-outbound-00.txt, proposes to use STUN for UDP and CR/LF for TCP. However, the I believe the next version of the draft will recommend STUN for both UDP and TCP. At IETF 63, it was noted that the CR/LF mechanism will not work because it may take several minutes for t

Re: [Sip-implementors] reINVITE Issue

You should not ignore the request because the UAC will eventually timeout and terminate the session. If the UAS does not like the SDP in the reINVITE, it usually rejects it with 488. This seems like the right choice if an endpoint does not support changing of SDP via a re-INVITE. However, most 4xx

Re: [Sip-implementors] Sending message without body with TCP

The Content-Length header is required with TCP. You must use: Content-Length: 0 >From RFC 3261, section 18.3 Framing In the case of stream-oriented transports such as TCP, the Content- Length header field indicates the size of the body. The Content- Length header field MUST be used wit

Re: [Sip-implementors] Not sending an ACK but a BYE for a CONFIRMEDDialog

You must always send the ACK to complete the 3-way handshake. You can send the BYE immediately after sending the ACK. - Original Message - From: "K Kaushik Sriram-A12869" <[EMAIL PROTECTED]> To: Sent: Wednesday, March 30, 2005 9:13 AM Subject: [Sip-implementors] Not sending an ACK but a

Re: [Sip-implementors] Re: [Sip] Via

- Original Message - From: "Paul Kyzivat" <[EMAIL PROTECTED]> > A way that is conformant with 3261 is to use the > ability to embed a sip header in a sip URI. This is > something like: > >Contact: > RFC 3261 actually discourages this sort of thing. Section 19.1.5 says: An

Re: [Sip-implementors] Stateless after first final non-INVITEresponse?

The proxy which forks a request will have multiple client transactions, and one server transaction (connected by the response context). When the first 200-OK is received, it is forwarded to the UAC and the server transaction is completed/terminated. The remaining client transaction are not terminat

[Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number

n 3261. I apologize for adding to the confusion. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] - Original Message - From: "Adam Roach" <[EMAIL PROTECTED]> To: "Bob Penfield&quo

[Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number

Section 8.1.1.5 says: The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The se

Re: [Sip-implementors] Query on Register

Sarika, A REGISTER with no Contacts is a "Fetch" request which returns all bindings (Contacts) for the address-of-record (AOR) in the To header. The response will be 200-OK, and all registered contacts/bindings for that AOR are returned in the Contact header. If there are no bindings for that AOR,

Re: [Sip-implementors] Which of the Call Flow is correct fortheCANCELRequest....????

be sent). BTW, according to RFC 3261, a transaction stateful proxy cannot forward the CANCEL until its has received a 1xx response. However, a stateless proxy does just forward the CANCEL. cheers, (-:bob - Original Message - From: "Atul Khandelwal" <[EMAIL PROTECTED]> T

Re: [Sip-implementors] Which of the Call Flow is correct for the CANCELRequest....????

Niether. The 487 will be a response to the INVITE, not the CANCEL. The UAC will normally get a 200-OK response to the CANCEL and then a 487 response to the INVITE. Orig UAC Proxy UAS |INVITE | | |--->| INVITE | |

Re: [Sip-implementors] Early session and Cancel

heers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] - Original Message - From: "Ramachandran Iyer" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]>; "Karthik M"

Re: [Sip-implementors] Early session and Cancel

The use of BYE is only required if the UAC wants to terminate a particular early dialog, but let other early dialogs or pending branches of the INVITE continue. CANCEL is used if the UAC wants to cancel the whole INVITE including all early dialogs and all outstanding forked branches of the INVITE.

Re: [Sip-implementors] Question on PROTO Test-Suite: c07-sip

inline. - Original Message - From: "Thomas Froment" <[EMAIL PROTECTED]> > Hi, > thanks for your response, > > Bob Penfield wrote: > > >The CANCEL must have the same to-tag as the INVITE, not the 1xx response. > > > I don't understand

Re: [Sip-implementors] Question on PROTO Test-Suite: c07-sip

The CANCEL must have the same to-tag as the INVITE, not the 1xx response. The ACK will have the same to-tag as the final response to the INVITE (usually 487 for a cancelled INVITE). RFC 3261, Section 9.1 states: The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields i

Re: [Sip-implementors] race condition

What UA1 does with a 200-OK response to the INVITE is same whether the CANCEL response comes first or not. Even though a CANCEL has been sent, the INVITE transaction must still be completed. All transaction complete independently. The CANCEL is a separate transaction, not part of the INVITE transac

[Sip-implementors] To-tags in CANCEL response & RFC 3665

Back in November of 2002, there was a discussion of whether or not the 200-OK for a CANCEL should have a to-tag. I reviewed the thread and it appears to me the consensus was that they should have to-tags in accordance with RFC 3261. However, none of the CANCEL examples in RFC 3665 have to-tags in t

Re: [Sip-implementors] Contact URIs

Sections 8.1.1.8 and 12.1.1 are quite clear that only SIP or SIPS URI is allowed. "The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog." "When a UAS responds to a request with a response th

Re: [Sip-implementors]

inline. - Original Message - From: <[EMAIL PROTECTED]> > > > -Original Message- > > From:On Behalf Of ext violin7 > > > > we know that proxy INVITE fork may cause UAC receive multiple > > 200ok for a initial INVITE.Considering the following scenario: > > > > ___(3)180

Re: [Sip-implementors] Question on creation of branch parameteratthe Transaction Layer

The from and to tags also need to be considered. If an INVITE request received provisional (18x) dialog establishing responses from multiple UAS's and reliable provisional responses (RFC 3262) were being used. The resulting PRACKs would have the same call-id & seq# but different to-tags. If only t

Re: [Sip-implementors] Request URI for INVITE for a B2BUA (actingasan ALG)??

The response to the UAC does contain the Via that was in the request sent by the UAC. It contains the branch tag that is used for transaction matching. See section 8.1.3 and 17.1.3 of RFC 3261. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Wob

Re: [Sip-implementors] proxy routing

If the request was sent by a loose-router, the top most Route header will (usually) be addressed to the proxy and have the ";lr" parameter. For an in-dialog request, if the previous hop was a strict router, it would send a Request-URI equal to the Record-Route header added by the proxy when the di

Re: [Sip-implementors] Multi-AOR Registrations

When the spec refers to UAC, it means a logical User Agent. Your phone is actually two logical User Agents in one physical device. Therefore, each UAC/Line can use a different Call-ID. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01

Re: [Sip-implementors] Query on Redirect Server

- Original Message - From: "Sreerekha Shenoy" <[EMAIL PROTECTED]> > hi > RFC 3261 states that a Redirect Server can either refuse a request or > respond with 3XX. > > Are there any specific requests to which it refuses ? One or more Contact headers will be included in the 3xx respons

Re: [Sip-implementors] request uri & where to send message?

rver? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] - Original Message - From: "Paul Kyzivat" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]> Cc: &quo

Re: [Sip-implementors] request uri & where to send message?

inline - Original Message - From: "Jonathan Rosenberg" <[EMAIL PROTECTED]> > inline. > > Bob Penfield wrote: > > inline > > - Original Message - > > From: "Paul Kyzivat" <[EMAIL PROTECTED]> > > > >

Re: [Sip-implementors] no timere for INVITE Client transaction

You are correct. There is no timer for the Proceeding state in an INVITE client transaction. In the case of a User Agent, it is up to the application to decide when to stop waiting, at which point it should send a CANCEL. For example, if the client is a SIP phone, the user would get tired of waitin

Re: Repost: [Sip-implementors] End-to-end retransmissions for re-INVITE?

The rules for re-INVITE are the same as for INVITE. The only difference is that the re-INVITE is a request within a dialog (i.e. it has from and to tags). Rules for the transaction layer and the TU are the same for a dialog initiating INVITE and an INVITE within a dialog. cheers, (-:bob Robert F.

Re: [Sip-implementors] request uri & where to send message?

inline - Original Message - From: "Paul Kyzivat" <[EMAIL PROTECTED]> > Bob - I have one question about your answer. See inline. > > Paul > > Bob Penfield wrote: > > If I understand what you are trying to do, your redirect server is > > essentia

Re: [Sip-implementors] request uri & where to send message?

If I understand what you are trying to do, your redirect server is essentially the "outbound proxy" for your client UA. What you want to do is insert a Route header in the request with the address/host of your redirect server (see section 8.1.2 of RFC 3261). Note that this Route header should have

Re: [Sip-implementors] contact header in 200 "OK"

Yes for a response to an INVITE request. A Contact header is required for a 2xx response to a request that establishes a dialog (i.e. INVITE or SUBSCRIBE): >From RFC 3261: 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVIT

Re: [Sip-implementors] SIP MESSAGE TYPES

The complete list of registered SIP methods, headers, option tags, reason codes, etc. can be found in the IANA registry at: http://www.iana.org/assignments/sip-parameters They include references to the RFCs that define them. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet

Re: [Sip-implementors] MUST all RFC 3261 Requests have From tags?

Ranga, Basically UACs and UASs set the tags and proxies do not. The UAC assigns the from-tag. RFC 3261 requires the UAC to include a from-tag in all requests. A forking proxy copies the from-tag in the received request to all of its outgoing requests. If the original request does not have a to-t

Re: [Sip-implementors] 2 questions on toTag in 200-for-CANCEL

A CANCEL request will have a To tag if the INVITE request being cancelled had a to-tag (e.g. a re-INVITE on an existing dialog). Section 9.1 of RFC 3261 states: The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in

Re: [Sip-implementors] Question on target refresh

Based on RFC 3261, a target refresh request is used by one UA to tell the other UA a new target URI to send future requests to (see section 12.2). The target URI is placed in the Contact header of the request. The route set (the set of URIs to include in the Route header of the request) is establis

Re: [Sip-implementors] Branch value in ACK for 2xx response.

The ACK for a 2xx is constructed the same as any other request within the dialog. The only exception is that it has the same Cseq as the INVITE. It gets its own unique branch id. An ACK for a non-2xx final response will have the same branch id as the original INVITE. All of these points are in the

Re: [Sip-implementors] Rule for BYE received without Tags

What all this means is that you always use the tags from the INVITE transaction that established the dialog in the BYE request. If your 3261-compliant UA sent an INVITE which arrived at a 2543-compliant UA, there may not be a to-tag returned in the response. The to-tag will be null/empty, and when

Re: [Sip-implementors] Proxy Processing Doubts

- Original Message - From: "Sp.Raja" <[EMAIL PROTECTED]> To: "Sip-Implementors" <[EMAIL PROTECTED]> Sent: Thursday, August 29, 2002 11:49 PM Subject: [Sip-implementors] Proxy Processing Doubts > Hi all, > > > RFC 3

Re: [Sip-implementors] Urgent : Registration related

- Original Message - From: "Krishnaswamy, Pavitra" <[EMAIL PROTECTED]> > Hi, > > I have a question about To Tags in register messages. > > Does the UA need to maintain the To tag received in a Registration > response(sent by the registrar) and include it in any subsequent > registration

Re: [Sip-implementors] RFC3261 says UAC can send BYE for an early dialog?

- Original Message - From: "Shankara, Udaya" <[EMAIL PROTECTED]> > Hi, >The caller may send BYE on early or confirmed dialogs as stated below. > Section 12.2.1.2 of RFC 3261 states the following: > >"A UAC SHOULD also terminate a dialog if no response at all is received > for the

Re: [Sip-implementors] RFC3261 says UAC can send BYE for an early dialog?

Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] - Original Message - From: "Arunachalam Venkatraman" <[EMAIL PROTECTED]> To: "Shankara, Udaya" <[EMAIL PROTECTED]>; "'Bob Penfield'" <[EMAIL PR

Re: [Sip-implementors] What shold do ?

In all three cases the call has been completed successfully because the UAS has sent the final response (200-OK). A CANCEL only works if it arrives at the UAS before the UAS sends a final response. The proxy should always forward the 200-OK for the INVITE on toward the UAC. The UAS responds to t

Re: [Sip-implementors] SIP uri for phone numbers

The hostname of the Request-URI should be the domain of the proxy since the proxy is suppose to know how to route the call. The rules for proxies in RFC 3261 state that when the proxy is not responsible for the domain in the Request-URI, it is suppose to forward it to the domain indicated in the R

Re: [Sip-implementors] early Dialogs..

; with a To Tag, > if a 100 Rsp comes with a To Tag (its a MAY & some implementations may > choose to add a To Tag to 100 Rsp), > even though the Rsp does'nt Match any of the existing Dialogs we SHOULD NOT > create an Early Dialog. We can just > give the 100 Tyring Rs

Re: [Sip-implementors] Let me know the mean of "terminated".

ything else that would result in a transport error. - Original Message - From: "Medhavi Bhatia" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]>; "Á¤Á¤¹®" <[EMAIL PROTECTED]>; "SIP Implementors" <[EMAIL PROTECTED]> Sent: T

Re: [Sip-implementors] Let me know the mean of "terminated".

In this case, I think you can interpret "terminated" to mean "Completed" or "Terminated". The proxy should send the final response upstream as soon as it has received a final response for all branches (client transactions) it created. - Original Message - From: "Á¤Á¤¹®" <[EMAIL PROTECTED]

Re: [Sip-implementors] Response retransmission

Sachin, It will match the transaction, but, according to the rules in 17.1.1, the proxy only generates an ACK for 300-699 responses. Also, it is not the same response so it cannot be considered a re-transmission. This may be an oversight in the spec, but I think falls into the category of innumer

Re: [Sip-implementors] Response retransmission

- Original Message - From: "Sachin Shenoy" <[EMAIL PROTECTED]> > Hi, > > If a proxy sends out an INVITE statefully, and gets a non-2xx response (say > 4xx), > it will send out an ACK locally. Now if it gets 2xx on the same branch, > it would consider this 2xx as retransmission of 4xx and

Re: [Sip-implementors] RFC3261 says UAC can send BYE for an early dialog?

The statement in section 15 is not an error. You are allowed to send a BYE instead of CANCEL for an early dialog to terminate only that dialog. This allows a UAC which receives provisional responses from more than one UAS (establishing multiple early dialogs), to terminate early dialogs it does no

Re: [Sip-implementors] rfc3261 - Stateless UAS

- Original Message - From: "Arunachalam Venkatraman" <[EMAIL PROTECTED]> > In 8.2.7 Stateless UAS Behavior > > o A stateless UAS MUST ignore CANCEL requests. > > o To header tags MUST be generated for responses in a stateless > manner - in a manner that will gener

Re: [Sip-implementors] question on handling ring-for-ever by CANCEL/BYE

see inline - Original Message - From: "Dong, Hwan" <[EMAIL PROTECTED]> > Hi, > > Consider the following scenario in the context of Fig 10 of bis-04: > > UAC UAS > ---INVITE-> > <--1xx- > ... > ...(Expiry timer is fired) > ... > > UAC sends INV

Re: [Sip-implementors] Authentication on Registration

Lorenzo, The reason 401 is used for the REGISTER message is because the proxy (which is also the registrar) is acting as the UAS for the REGISTER transaction. If the proxy did actually proxy the REGISTER request on to a registrar and the proxy needed credentials, it could respond with 407. Endpo

  1   2   >