Re: [Sip-implementors] Can B2BUA add record-route?

Yes - by the Contact. If the "B2BUA" *doesn't* use its own Contact then it isn't acting as a UA and so isn't really a B2BUA. Paul Ivar wrote: > > It alters Contact: header field to it's own value, normally b2bua tries > hide as much as possible, so actual users won't see actual desti

Re: [Sip-implementors] Can B2BUA add record-route?

s of section 12. That should answer most of your questions. Paul > On 6/12/07, *Paul Kyzivat* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Yes - by the Contact. > > If the "B2BUA" *doesn't* use its own Con

Re: [Sip-implementors] Behaviour on receipt of second non-2xx response

Scott Lawrence wrote: > I think this can only happen if you're talking to something that's > broken - either a UA that sends more than one final response to the same > request, or a proxy that is returning more than one to you (it is > correct for a proxy to return multiple 2xx responses, but an

Re: [Sip-implementors] Multiple contacts in register 200 OK response

Richard wrote: > Suppose UA1, which is behind NAT, is registering a public SIP server. > UA1 > (only necessary headers are shown) > REGISTER sip:serviceprovider.com > To: > From: > Contact: This is incorrect. The expires parameter is a *header* parameter, not a URI parameter. It ought to be:

Re: [Sip-implementors] Behaviour on receipt ofsecond non-2xx response

rds the response. Paul > Regards, > > Vishal Mathur > Symantec Corporation > www.symantec.com > _ > Office: +91-20-66067655 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of >

Re: [Sip-implementors] Can 181 Call Is Being Forward have SDP?

181 should follow the rules for any other provisional response. So you could include SDP in the same cases where you might if it were a 183. You are governed by the general offer/answer rules. Paul Sumin Seo wrote: > Hi All, > > Let's say I want to play announcement to let user know th

Re: [Sip-implementors] Query on Out of Dialog bye

Why would you want to generate an out-of-dialog BYE? It would be invalid and useless. Paul sarthakd wrote: > Hi, > > I am trying to create an OUT OF DIALOG BYE. > > Logically, one of the options would be to change the from or to tags. Just > wanted to know if I send a BYE without 'to

Re: [Sip-implementors] Call hold and a = inactive

varun wrote: > Hi, > If user B wants to put user A on Hold, it can send a = > sendonly to A and expects A to return a = recvonly. > This way there is a one way audio channel open from B > to A. > What if user A responds with a = inactive..is that > valid? Yes. > Does it mean that media streams

Re: [Sip-implementors] Call hold and a = inactive

Andrea Rizzi wrote: > Just read section 6.1 . > Should the attribute be missing in the answer, it implicitly means sendrecv, > i.e. it is forbidden! Agree it is forbidden now. But in RFC 2543 there was no specification of this. So receiving none of the direction attributes in the response can

Re: [Sip-implementors] Call hold and a = inactive

You can view this as a limitation or a feature. Its a limitation in that you can't in general communicate that you are carrying out some particular feature. Its a feature because it allows interoperation when there is no standardization of features. (E.g. you don't need to know about HOLD. All

Re: [Sip-implementors] Question about 200 OK for INVITE

For questions like this you should see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-01.txt. Paul River wrote: > Hello All, > > I have a question about 200 OK for INVITE. > Let's suppose an UAC sends out an INVITE/SDP, then the UAS replys with > 180/SDP and 200

Re: [Sip-implementors] INVITE with no SDP - provisional response with SDP

Stephen Paterson wrote: > Hi all, > > Is it at all meaningful for an unreliable 1xx response to an INVITE to > contain an SDP body when the INVITE itself did not? I'm aware of the > situation in the reliable case. It is certainly allowed. > I'm rather hoping that this is not allowed for the sa

Re: [Sip-implementors] Question on Requests within a Dialog (Sec 12.2)

Girish, There are no rules here. IETF only standardizes the protocol, not the construction of stacts that support it. You are free to construct the stack any way you, and the users of your stack, desire. Paul Girish Moodalbail wrote: > Thanks Robert for the response. > > From your re

Re: [Sip-implementors] pre conditions

; > Michael > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:sip- >> [EMAIL PROTECTED] On Behalf Of Robert Sparks >> Sent: 18 July 2007 15:18 >> To: Jacob Fritz-A17682; Paul Kyzivat >> Cc: sip-implementors@lists.cs.columbia.edu >> Subje

Re: [Sip-implementors] relationship between contact URI in REGISTER andrequest uri in INVITE

I largely agree with Jeroen. The UA is the master of its own address. It tells others the address(es) where it is willing and able to receive requests. REGISTER is one way it can tell others (the registrar) its address(es). This is much like postal addresses. A postal address might be:

Re: [Sip-implementors] relationship between contact URI in REGISTER andrequest uri in INVITE

ression that lots of UAs don't care what is in the R-URI as long as it arrives at the correct address and port. > Is there no explicit mention that a proxy should replace the request URI > with the contact that the registrar stored upon registration? Of course there is. > It

Re: [Sip-implementors] relationship between contact URI in REGISTER andrequest uri in INVITE

oh, duh. The Linksys device is the victim here, not the culprit. Paul Paul Kyzivat wrote: > > Stephan Steiner wrote: >> Actually this proxy/registrar (the Linksys SPA9000), does things in a rather >> interesting way: > > Well... you will note that my email ad

Re: [Sip-implementors] relationship between contact URI in REGISTER andrequest uri in INVITE

Stephan Steiner wrote: > >>> >>> Could you tell me where exactly? I must have looked in the wrong >>> sections as I've been unable to find it. >> >> Well, its not quite as explicit as I was thinking. :-( > > That's what I feared. To make sure I get this, what do you think should > happen in t

Re: [Sip-implementors] relationship between contact URI in REGISTER andrequest uri in INVITE

at they do, but this behavior seems at least peculiar. Thanks, Paul > If I take two other phones in my network, it looks the same (with the > obvious differences plus whatever differences that are due to different > implementations by different manufacturers). > > Rega

Re: [Sip-implementors] Relevance of the session version field in SDP answer

Its clear from 3264 that just as an offer can change the session, the answer may change as well. Think of the sip session as having one currently active session description on each end. Via subsequent offer/answer either one of the session descriptions may be changed by providing a suitable SDP

Re: [Sip-implementors] Non-subscribe mechanism for creating subscription

Anshuman S. Rawat wrote: > Hi All, > > Sec 3.2 in RFC 3265 states - > > " If any non-SUBSCRIBE mechanisms are defined to create subscriptions, >it is the responsibility of the parties defining those mechanisms to >ensure that correlation of a NOTIFY message to the corresponding >sub

Re: [Sip-implementors] Query in DisplayName?

Somesh S Shanbhag wrote: > Sudhir, > > I dont think there is any restrictions on DisplayName length. Right. It just can't exceed the size of the message. :-) > Each header should not exceed 998 characters and 78 characters per line > (RFC 2822) I don't believe those limitations apply

Re: [Sip-implementors] URI parameter in To and From headers

I haven't gone back to study 3261 specifically about this, but based on my understanding I think: The sender of an out of dialog request must ensure that there is no tag in the To-URI. Depending on where the URI came from it may be necessary to remove the tag. (When creating new out of dialog t

Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]

Dale has covered this. For the original poster, Stefan: there is a lot of written information on this subject that you don't seem to be familiar with. The most obvious are RFCs 3261 and 3264. For a more complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswe

Re: [Sip-implementors] A question about SDP direction attribute

Vikram Chhibber wrote: > As per RFC 3264, a missing direction attribute in offer SDP default is > sendrecv. What is the default considered in case of Answer SDP? > I assume that it should be again sendrecv and the default does not > change whether it is offer or answer. There are some issues bec

Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]

there is no serious harm in incrementing it in this case too if you haven't kept track of whether it has changed.) Paul Stefan Sayer wrote: > > Paul Kyzivat wrote: >> Dale has covered this. For the original poster, Stefan: there is a lot >> of written information o

Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]

From what I can see of the example below there is only one problem - the version number in the 2nd answer should have been incremented. As written, the offerer could proceed on the assumption that the answer has not changed. In this case that would do no harm. In some other cases it might.

Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]

Valentin Nechayev wrote: >> Stefan Sayer <[EMAIL PROTECTED]> wrote: > >>> complete treatment, see >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt >> where you write in 4.2.5. Subsequent Offers and Answers: > >> o In the o-line, only the version number

Re: [Sip-implementors] SDP in unreliable 183 and 200

The specs say that the SDP in the 183 and the 200 must be the same. They do not say what to do if they are different. Nor do they require the recipient to check if they are different. The maxim of "be conservative in what you send, liberal in what you accept" can help here, but only to a point.

Re: [Sip-implementors] SDP in unreliable 183 and 200

implementation. If a 183 is >> received, followed by a 200 ok with a different version, then the 200 >> ok should be treated as a stray without ANY correlation with the 183. >> If asterisk sends different version in 183 and 200 ok, then its >> plainly a bug and should be t

Re: [Sip-implementors] SDP in unreliable 183 and 200

ect > the already established media stream in line with being liberal of what > we receive since it clearly violates the specs? The only benefit in > doing so is if not only the version was different but also the session > description itself is different. In which case I would stron

Re: [Sip-implementors] inclusion of non standardized parameters in Request-URI

jorma h wrote: > I have a query on the inclusion of non standardized parameters in the > Request-URI. I think that as long as the R-URI is not modified, that such > parameters would be passed intact. But my real question is whether it is > "legal" to do. If I have some special information I'd lik

Re: [Sip-implementors] A question regarding session timer

Wen, *Every* re-INVITE or UPDATE redetermines session timer status, whether you want it to or not. So if you have occasion to do one before the time of the scheduled session refresh, then it in effect preempts the session timer refresh. The way I think of it is that the session timer establish

Re: [Sip-implementors] INVITE with Expires header

Marco, I've wondered about this too. Obviously the UAC is free to send a CANCEL at any time, whether it included an Expires in the INVITE or not. So the value of this header has to be in what effect it has on the UAS. If the UAS does as specified, then there is indeed no reason for the UAC to

Re: [Sip-implementors] INVITE with Expires header

7;t sure things. Thanks, Paul Marco Ambu wrote: > Paul Kyzivat ha scritto: >> Marco, >> >> I've wondered about this too. >> >> Obviously the UAC is free to send a CANCEL at any time, whether it >> included an Expires in the INVITE or not. So the

Re: [Sip-implementors] A question about SIP offer answer

You can get answers to a lot of your questions in http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-03.txt More inline. Paul Vikram Chhibber wrote: > I have further queries on re-INVITE without SDP, > If this is a query mechanism where the UAS returns the session >

Re: [Sip-implementors] SUBSCRIBE Expiry Timer

This is a battle between the needs/desires of the subscriber and the needs/desires of the notifier. - a large value minimizes the traffic - a small value decreases the lag before a failure of the peer is recognized Each device must decide what is an appropriate tradeoff between those confli

Re: [Sip-implementors] Early media and forking calls

When you get the 200 from C you can assume that the proxy sent a CANCEL to B. But you cannot assume the CANCEL will work. It is still possible to receive a 200 from B. You need to be prepared to handle that case too. (The usual thing to do is send a BYE on the dialog of any subsequent 200 respo

Re: [Sip-implementors] Early media and forking calls

A has another problem it must deal with: It provided one port on which it will receive media. B and C may both be sending media to that port. A has no good way to know which media is from B and which is from C. This is true even after receiving the 200 from C. It must be clever to figure out wh

Re: [Sip-implementors] Early media and forking calls

can switch the sessions serially by sending an INVITE/Replaces to A. Paul > That will do the trick, will it? Maybe it is also possible to use UPDATE in > some way > > // Andreas > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PR

Re: [Sip-implementors] SUBSCRIBE Expiry Timer

IFY's can come. > > is there any way to avaoid duplicate NOTIFY...? > > will session timer on subscribe dialog holds good? There is no need for session timer on a subscription, because the expiry timer on the subscription serves exactly the same purpose. Paul >

Re: [Sip-implementors] Transfer End-Game...fast BYE

Peter Musgrave wrote: > Greetings, > > I have encountered a call flow in which a UA is sending a REFER in-dialog > and then terminating the dialog before a 202 is received > > (dialog established) > > | > |<-BYE---| Apparently the UA wants to be out

Re: [Sip-implementors] Automatic Callback in sip-packages

I believe the question is really not whether the terminal is "available", but rather whether it would accept your call if you made a call. Its quite possible that even though it is engaged in a call it would still accept a call from you, or that even though it is not engaged in a call it might

Re: [Sip-implementors] Transfer End-Game...fast BYE

[EMAIL PROTECTED] wrote: >From: "Peter Musgrave" <[EMAIL PROTECTED]> > >I have encountered a call flow in which a UA is sending a REFER in-dialog >and then terminating the dialog before a 202 is received > >(dialog established) > >| >|<

Re: [Sip-implementors] ReREGISTER in SESSION

I agree with dale that this is the way registration was intended to be used in SIP. For better or worse (IMO worse) some systems couple registration with authorization to make calls, or even to continue a call that is in progress. If you work with a system like that then you need to follow what

Re: [Sip-implementors] Regarding Third Party Registration

What do you want to know? You are correct that this is a third party registration. Its legal if the registrar authorizes it. (Many won't.) Paul friend friend wrote: > Folks, > > The below message is a Third Party Registration message > > From: > To: > Contact: > > P

Re: [Sip-implementors] Doubt regarding sequence numbers

nabeel mohamed wrote: > Hi all, > > Can anyone of you clarify me the below ? > > RFC 3261 says, > If the remote sequence number in a dialog is not empty, and a request is > received with a sequence number lower than the remote sequence > number, then the request should be rejected with response

Re: [Sip-implementors] Accept-contact and forking

[EMAIL PROTECTED] wrote: > > Telefónica Móviles España, S.A. > > > > > Hi > > According to RFC384

Re: [Sip-implementors] max size in byte(in character) of Tag in SIp

As a hint to people who ask this question: The size of any field in the message is bounded by the total size of the message. (Duh!) So you can manage these things by representing the tokens of the message by a reference to a substring of the whole message. That way every token is a fixed size

Re: [Sip-implementors] Handling SIP Duplicate Headers

You are asking for guidance on how to behave when interacting with a non-compliant UAC. We typically don't standardize that. So you may do as you see fit. One possible way of responding would be to take the originating message and transform it into a response, preserving the incorrect headers.

Re: [Sip-implementors] FW: quick clarification regarding invalid SIP INFO handling

Katsidoniotis, Manolis wrote: > > Hello > > rfc 2976 states > > page2 > The INFO method is not used to change the state of SIP calls, or > the > parameters of the sessions SIP initiates. It merely sends > optional > application layer information, generally related to the ses

Re: [Sip-implementors] FW: quick clarification regarding invalid SIP INFO handling

ease the transaction) > and the dialog is in early state (as here) then should I release the > call or should I proceed ? You should ignore the info and leave the dialog as is. Take a look at http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-06.txt > Thanks again in

Re: [Sip-implementors] Is route set be recomputed while sending ACKfor retransmitted 2xx?

om: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Kyzivat > Sent: Friday, October 19, 2007 6:38 PM > To: KASTURI Narayanan (kasnaray) > Cc: praveen dandin; Sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Is route set be recomputed w

Re: [Sip-implementors] Is route set be recomputed while sending ACKfor retransmitted 2xx?

I agree with Kasturi regarding the meaning of that text. It allows a proxy that record-routes to provide a different value to the UAS and UAC. However that mechanism is no longer in favor. It is considered preferable for the proxy to "double record route" when it proxies the request and then do

Re: [Sip-implementors] Is route set be recomputed while sending ACKfor retransmitted 2xx?

at carry the same to-tag. So that excludes responses from different UASs due to forking. If these had different R-R, then that would constitute changing the route for a dialog, which isn't allowed. Paul > Thanks, > Praveen > > */Paul Kyzivat <[EMAIL PROTECTED]>/* wr

Re: [Sip-implementors] rfc3959 - The Early Session Disposition Type

I'd be very interested to hear of *anybody* that has implemented this. I have the impression there are none. Paul Brett Tate wrote: > Look closer at the examples within section 7. > > The caller offered port 2 in INVITE. The caller answered the early > offer with port 20002. Thus

Re: [Sip-implementors] tel uri query

Devaki D wrote: > Hi All, >I have some doubts regarding the implementation of tel URI as per RFC > 3966.Any inputs will be highly appreciated. > > 1)Is it possible to have tel: URI as request URI in methods other than INVITE > and REGISTER i.e in OPTION,PRACK,ACK,CANCEL,BYE, Notify,Subscri

Re: [Sip-implementors] proxy=replace

Vitali Fomine wrote: > Hello, > > REGISTER sip:home.local SIP/2.0 > Via: SIP/2.0/TCP 192.168.0.1:7305 > Max-Forwards: 70 > From: > ;tag=e9558a13a35b47b5ab199c563e3709c1;epid=ff2de542ac > To: > Call-ID: f8f03275f1f64bc5873dd58a3ec71201 > CSeq: 1 REGISTER > Contact: ;methods="INVITE, MESSAGE, >

Re: [Sip-implementors] NOTIFY Error Response Problem

[EMAIL PROTECTED] wrote: > > Hi Vinay, > > "REFRESH" SUBSCROBE > |--->|--->| > Will create the subscription again on UAS because for UAS it is a > totally new SUBSCRIBE, previous subscription has been deleted. Since the subscriber thinks this is a refresh, the request will have a to

Re: [Sip-implementors] 180 with body AFTER 183 with body - is it valid

Since the SDPs are the same, I assume that the responses are from the same UAS, and carry the same to-tag. You didn't say if the responses were reliable provisionals, so I will assume they were not. (The answer is different if they are.) In that case the answer is that this is entirely legal.

Re: [Sip-implementors] Proxy behavior for SUBSCRIBE request

Pandurangan R S wrote: > Thanks for the reply. > > In case the proxy receives a SUBSCRIBE (with the request uri > [EMAIL PROTECTED] the proxy is responsible for this domain) > for an Event that it does *not* understand, should it > a) Reject the SUBSCRIBE with 489 - Bad Event OR > b) Forward the

Re: [Sip-implementors] 180 with body AFTER 183 with body - is itvalid

Attila Sipos wrote: >>> it is not comparable to forking scenario. > > As I tried to explain in my e-mail, a UAS can do forking by itself > if it sends different to tags in its responses. > Though not usual, it is perfectly valid. > > If the UAS sent these 2 responses without different to tags,

Re: [Sip-implementors] page-mode instant-messaging question

Vikram Chhibber wrote: > Hi, > > I want to perform page-mode instant messaging (using SIP MESSAGE) on a > dialog created by INVITE. This INVITE I want for establishing a dialog > on which I can send SIP MESSAGE only and there will be no media. I do > not want msrp either. The first question is

Re: [Sip-implementors] Error in incoming req uri, what to do?

The UA receiving this must (by definition) be the UAS. It *ought* to be the intended recipient of the request (leaving aside some B2BUAs which have different issues). As the intended recipient, the URI ought to be one it knows about. Since this one is malformed (and the UA probably wouldn't *in

Re: [Sip-implementors] Error in incoming req uri, what to do?

ne, or if it is ok just to > ignore it? It might be that the reqln uri is soo messed up that it will be > hard to identify this as an SIP request... I don’t know if a # could have > such effect > > // Andreas > > -Original Message- > From: Paul Kyzivat [mailto:[EMAI

Re: [Sip-implementors] Error in incoming req uri, what to do?

Attila Sipos wrote: > > I seem to remember some discussion about the # and # character a > long time ago. > > You could respond with 400 Bad Request but I think it would be best > if you just treated it as if the # had been escaped. I know it's not strictly > compliant but: > 1. I don't thin

Re: [Sip-implementors] How to know active call status,using SIP

If I understand you the IPPBX is sitting in the middle of the call, between the two endpoints and wants a way to verify that the two endpoints continue to function. Right? If the IPPBX is a B2BUA then it may, at any time after the call is established, send a request to either of the ends. This

Re: [Sip-implementors] page-mode instant-messaging question

wrote: > Hi, > I am not sure of your use case but I think your requirement could be > achieved if you send INVITE/ACK without any content (SDP media or something > else). This will make session hence end-to-end dialog for you. I beg to differ. If you send the INVITE without any content t

Re: [Sip-implementors] Error in incoming req uri, what to do?

[EMAIL PROTECTED] wrote: >From: =?iso-8859-1?Q?Andreas_Bystr=F6m?= <[EMAIL PROTECTED]> > >I'm kind of in the middle of the stack provider and the UA provider here... >But I guess I should interpret your responses that in case of a sip uri > with >the # error, there is no specifi

Re: [Sip-implementors] Error in incoming req uri, what to do?

nd a sip response? IMO that is indeed the case. Paul > // Andreas > > -Original Message- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: den 14 november 2007 22:43 > To: Andreas Byström > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Si

Re: [Sip-implementors] Error in incoming req uri, what to do?

From: Paul Kyzivat <[EMAIL PROTECTED]> > >The UA receiving this must (by definition) be the UAS. It *ought* to be >the intended recipient of the request (leaving aside some B2BUAs which >have different issues). As the intended recipient, the URI ought to be >

Re: [Sip-implementors] page-mode instant-messaging question

> This way small applications like synchronization of some part of my > address boob with peer etc. can be developed where MSRP will be an > overkill and page-mode messaging may have performance impact on the > network. > Any opinion on this? > > On Nov 15, 2007 7:40 PM, Pau

Re: [Sip-implementors] Error in incoming req uri, what to do?

Andreas > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul > Kyzivat > Sent: den 15 november 2007 15:30 > To: [EMAIL PROTECTED] > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Error in

Re: [Sip-implementors] How to know active call status,using SIP

Brett Tate wrote: > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, November 15, 2007 9:24 AM >> To: Amit Lobo >> Cc: Sip-implementors@lists.cs.columbia.ed

Re: [Sip-implementors] how to prevent forking?

라스토기 wrote: > Request-Disposition of RFC 3841 prevents or guides forking. Hope it helps I've never heard of anyone implementing that. Has anybody? Thanks, Paul > Vipul Rastogi > Engineer, Business Management Team > Telecommunication Network Business > Samsung Electronics C

Re: [Sip-implementors] page-mode instant-messaging question

Vikram, I don't think you should do this at all. But if you are going to do it, why don't you follow some precedent such as what MS does. I don't have the details, but I expect it wouldn't be hard to come up with them. Paul Vikram Chhibber wrote: > Dale, the problem here is that the in

Re: [Sip-implementors] Session Timer + one Scenario

Inline. Paul [EMAIL PROTECTED] wrote: > Comments inline... > > Regards, > Nataraju A B > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > sumanth achar > Sent: Friday, November 16, 2007 7:47 PM > To: sip-implementors@lists.cs.columbia.edu

Re: [Sip-implementors] Query

라스토기 wrote: > 'sendonly' is part of SDP, UA (we) know/s that call via this SDP is put on > hold. If you put 'sendonly' in SDP you ought to know why, whether it is for hold, or because you are just a music player, or whatever. Nobody has to tell you why. If you *receive* SDP with 'sendonly'

Re: [Sip-implementors] Directionality Attribute in UPDATE Request

What is impractical about it. UPDATE may be used for a mid session o/a. This is perfectly fine as long as UPDATE is supported. Paul 라스토기 wrote: > It is valid but not practical but looks very interesting as one can avoid > 3-way handshaking of RE-INVITE by using UPDATE. > > Vipul Rasto

Re: [Sip-implementors] Directionality Attribute in UPDATE Request

Paul > Serhad > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat > (pkyzivat) > Sent: Monday, November 19, 2007 8:40 PM > To: [EMAIL PROTECTED] > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors]

Re: [Sip-implementors] SDP answer from UAS.

Raghu Thakur wrote: > The SDP offer for the FAX stream by UAC can be sent in case UAC > already has a voice call established ( media over voice is already > present) with UAS. Offer can be seen as an attempt by the UAC to > change its existing audio stream to T.38 FAX. > > The SDP negotiation m

Re: [Sip-implementors] SDP answer from UAS.

narendra singh wrote: > Hi Attlia, > > Thanks for the reply. > What corrective actions has to be taken at user A, if the mentioned answer > is received. That's difficult. Since the violation came in a response you can't respond to it with an error. You could simply send a BYE, or you

Re: [Sip-implementors] UPDATE on early dialog

Murali Radhakrishnan wrote: > Hi, > > I have an Application Runing on a Weblogic Sip Server (BEA). In Case 1 > - Non Reliable scenario, when i send a UPDATE request, it reaches the > destination (Request-URI) is set to the target. > > Case 1 :- Non- Reliable > > A (UAC)

Re: [Sip-implementors] Sip-implementors Digest, Vol 56, Issue 28

Vikram Chhibber wrote: > Andrea, I was in the impression that sending BYE terminates the > session which includes all the dialogs. Can anyone confirm this? I can refute it. Look at RFC 5057. Paul > ~Vikram > http://www.veraznetworks.com/ > > On Nov 28, 2007 1:56 PM, Andrea Rizzi <[EMA

Re: [Sip-implementors] Content-Langauge Header in SIP

The Content-Language header generally has nothing to do with what language the recipient (human) of the message speaks/understands. It has to do with the language used in the corresponding body part. If the request is an INVITE which contains an SDP body, then it would pertain to what language

Re: [Sip-implementors] Session Timer related doubts

shweta kavishwar wrote: > Hi, > Please verify if this understanding is correct. > > Consider the following scenario: > UAC supports session-timer extension & UAS dosent. > UAC sends an INVITE request with Session-Expires header & Supported:timer. > > UAS behavior: > - It either blindly copies

Re: [Sip-implementors] Combining alert-info with file-transfer-mech

Huh??? I don't understand what you have in mind. Paul Arjun Roychowdhury wrote: > Hi, > I am working on a scenario where Alert-info would be included in an INVITE > request. However, in the same request, I want to bind the 'download' > mechanism of the file pointed to in Alert-Info with

Re: [Sip-implementors] Combining alert-info with file-transfer-mech

t HTTP. To boot look inside my > SDP to see more meta-information that will help you download, including > an MD5 checksum to ensure you downloaded what I think I asked you to > download" > > regds > arjun > > On Nov 30, 2007 5:53 PM, Paul Kyzivat <[EMAIL PRO

Re: [Sip-implementors] Combining alert-info with file-transfer-mech

AIL PROTECTED]> > Content-Type:application/sdp > Content-Length: > ... > ... > m=message TCP/MSRP * > . > . > . > a=path:msrp://myurltoringtone:/342sf;tcp > > > > On Dec 1, 2007 2:18 PM, Paul Kyzivat <[EMAIL PROTECTED] > <mailto:[EMAIL PROT

Re: [Sip-implementors] To and Request-URI

I agree. In general the To-URI isn't useful for *anything*. Paul Sanjay Sinha (sanjsinh) wrote: > Request-uri number > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf Of SungWoo Lee >> Sent: Tuesday, December 04, 2007 12:04 AM >> To:

Re: [Sip-implementors] Query on Unicaststream media

vinodh kumar wrote: > Hi, > > > User A and User B is in call. User A puts the call on hold now the music is > played to User B(Music on hold). > > Invite sent from A to B has media marked as sendonly. Is it mandatory to > have connection IP and port info in SDP sent by A. As the media is sendo

Re: [Sip-implementors] Query on Unicaststream media

sent to >the port number one higher than the number indicated. The IP address >and port present in the offer indicate nothing about the source IP >address and source port of RTP and RTCP packets that will be sent by >the offerer. > > Thanks, > vinodh > &

Re: [Sip-implementors] Clarificaiton on Require/Supported header

Oh, duh. The * is there among the token chars. I agree with Brett. Paul Brett Tate wrote: >>I want to know whether the INVITE request having >> Require/Supported header with value as "*" is similar to that >> of INVITE request having Require/Supported header with all >> the valid o

Re: [Sip-implementors] Clarificaiton on Require/Supported header

You should be able to answer such questions for yourself simply by reading the syntax in 3261: Require = "Require" HCOLON option-tag *(COMMA option-tag) option-tag = token token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

Vikram Chhibber wrote: > On Dec 11, 2007 12:42 PM, Brett Tate <[EMAIL PROTECTED]> wrote: >>> Please confirm my understanding of subscribe for MWI. NOTIFY >>> should not be sent to a UA unless a SUBSCRIBE has been sent to it. >> RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions.

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

Brett Tate wrote: > As far as I know, "unsolicited" NOTIFY violates rfc3265 (however I don't > call notifies related to administrator configured subscriptions > "unsolicited"). And I'm not aware of an RFC allowing NOTIFY to create a > dialog (beyond what can occur because of forking). > > RFC32

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

Brett Tate wrote: >> Certainly the motivation for the existing wording was to >> accommodate REFER, and I suppose similar arrangements. > > Yes; and subscriptions created through configuration (section 3.2.2). > > >> NOTIFYs that don't contain a to-tag don't identify an >> expected dialog, so

Re: [Sip-implementors] Is session-expires be sent in 2xx response even though UAS doesnt support session timer?

It seems I have to say this every few weeks... *WHY* is the UAC requesting a session timer??? The real purpose of session timer is so that a record-routed proxy can cause one of the UAs to send periodic messages - confirming for the proxy that the session is still active. (A proxy isn't allowed

Re: [Sip-implementors] Is session-expires be sent in 2xx responseeventhough UAS doesnt support session timer?

I agree with Nataraju. In general a UA should not be including anything it doesn't understand it its requests or responses. If a request contains unknown headers they shouldn't be included in the corresponding responses. This is in contrast to the behavior of a proxy, which should be passing t

Re: [Sip-implementors] Is session-expires be sent in 2xx response even though UAS doesnt support session timer?

questionable as requesting it at all. Paul > Thanks, > Raj > > > > On Dec 12, 2007 6:15 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote: >> It seems I have to say this every few weeks... >> >> *WHY* is the UAC requesting a session timer??? >

  1   2   3   4   5   6   7   8   9   10   >