What is the real concern here?
Why would you care if the caller has registered? SIP does not require
registration to send requests.
I guess you either are concerned that the caller is somehow authorized
to call you, or call anybody, or else you are concerned with whether you
can trust the
Cc: Paul Kyzivat
Subject: [Sip-implementors] Expected behavior for an INVITE sent without
an offer
Hi,
What should be the behavior of UAC when an INVITE is sent without offer
and Require 100rel and it receives non-reliable/reliable 18x response
without SDP?
Should the transaction
As already asked, are you presuming use of Session Timer to drive the
sending of the UPDATEs?
Assuming A and B are both UAs, not proxies, then there is no need to use
session timer to negotiate keep-alives. (Session Timer is primarily for
the benefit of proxies in the route.) A UA may send
On 12/22/11 1:14 AM, Johnson, Michael A wrote:
I am seeking clarification on the History-Info RFC 4424
In a transit scenario, an incoming call that is immediately redirected to
another party, I am getting rejected based on the History-Info field.
This is only where there is no A-party
On 12/21/11 3:09 AM, Saul Ibarra Corretge wrote:
Hi,
On Dec 21, 2011, at 8:00 AM, William Scott wrote:
On 21 December 2011 17:10, Alex Balashovabalas...@evaristesys.com wrote:
Is your concern about the two RR headers, or the double lr parameter?
The double lr parameter.
When my ATA
On 12/8/11 8:16 AM, Joegen Baclor wrote:
On 12/08/2011 06:47 AM, Worley, Dale R (Dale) wrote:
From: Joegen Baclor [jbac...@ezuce.com]
I am implementing an RLS service that shares load via DNS/SRV records.
Let us say I have 2 RLS servers sharing the load equally for 200
subscribers. In an
The examples below look like some sort of conformance test, rather than
cases that would actually be encountered in practice. If so, I suppose
either you are implementing the tester and looking for what response to
expect, or else you have failed a conformance test and are looking for
an
On 12/6/11 7:00 PM, Stefan Sayer wrote:
Hello,
I am wondering what to do with an SDP in a 200 to an UPDATE without
SDP in an established dialog, for example as a response to a session
refresh triggered by SST. There is two cases:
- the SDP has not changed (to what is established)
-
On 12/7/11 12:06 AM, Brez Borland wrote:
On Tue, Dec 6, 2011 at 3:35 PM, Paul Kyzivat pkyzi...@alum.mit.edu
mailto:pkyzi...@alum.mit.edu wrote:
The examples below look like some sort of conformance test, rather than
cases that would actually be encountered in practice. If so, I
On 11/23/11 9:21 PM, Robert Szokovacs wrote:
Hi,
I have the following setup: a B2BUA based on sipstack A and a mediaserver,
based on sipstack B.
Themediaserver sends a REFER to the B2BUA which starts to send NOTIFYs
according to the progress of the REFERred call: for example: 100, 183,.
On 11/22/11 1:27 AM, Kumar, Puneet (Puneet) wrote:
Hi All,
I am working on a implementation issue where SIP message flow is:
UAC UAS
-INVITE w/o SDP
---200 OK w/SDP
Here UAC sends a slow start INVITE to UAS.
On 11/22/11 2:04 AM, Iñaki Baz Castillo wrote:
Hi, imagine a Proxy which first receives a 480 response and forwards
it upstream to the UAC (and receives the ACK) but later, for some
annoying reason, the Proxy receives a 200 for the same client
transaction.
Should the client discard it? or
On 11/22/11 11:40 AM, Adam Frankel (afrankel) wrote:
Hi All,
I am seeing a scenario for an established call in which an outbound
reINVITE is being done, the far end is sending a TRYING and then a REFER
immediately. We are rejecting this REFER with a 400 Bad Request because
the INVITE
On 11/15/11 11:24 PM, Worley, Dale R (Dale) wrote:
From: Brett Tate [br...@broadsoft.com]
Concerning the quoted-string and quoted-pair BNF, it allows useless
escaping of characters within the quoted string. For instance,
value can uselessly be escaped as \v\a\l\u\e. Are they
equivalent?
Kutay,
Yes, you need to handle this.
Each contact can have its own expiration time setting, which is what you
see here. The way to treat this is to consider the value in the Expires
header (if any) as a default value for every Contact, which is then
overridden by an expires header field
On 11/9/11 9:47 AM, Worley, Dale R (Dale) wrote:
From: Sairam POKKUNURI [sair...@ipinfusion.com]
we dont care what type of phones or their properties are if they can send
and recieve properly
OTOH, when you discover that some element is *not* sending properly, it is
very useful if you can
On 11/3/11 1:10 PM, Brett Tate wrote:
Howdy,
RFC 6337 and 3GPP TS 24.610
(http://www.3gpp.org/ftp/Specs/html-info/24610.htm) appear to be in conflict
concerning resuming from hold. However, it may just be a poor interpretation
of 3GPP TS 24.610 when a sendonly offer (from X) is answered
On 11/3/11 3:10 PM, prakash k wrote:
Hi All,
In Replaces: whether the order is mandatory, ( what is meant is) followe
by callid information ,to-tag should come first then only from-tag
as per RFC 3891
ABNF
Replaces= Replaces HCOLON callid *(SEMI replaces-param)
I think I recall some work from long ago that banned use of
Content-Transfer-Encoding. (But I'm not sure I remember it right.) It
might have been Cullen who did it.
Does that ring any bells?
Thanks,
Paul
On 11/1/11 11:00 AM, Worley, Dale R (Dale) wrote:
From: Olle E.
On 11/1/11 11:23 AM, Hadriel Kaplan wrote:
And someone sends binary encoded payloads for DTMF indications in SIP NOTIFY
requests - I don't remember who it is, but I remember it because it's so
crazy (the MIME body's content is literally an RFC 2833 RTP DTMF event
packet, minus the IP and
+1
On 10/31/11 10:46 AM, Worley, Dale R (Dale) wrote:
From: Olle E. Johansson [o...@edvina.net]
RFC 3261 is not totally clear in the topic of AORs you can register
to. It seems to indicate any URI, but mentions usernames in most
examples.
In practice, what you can register to is what the
See section 5 of RFC 6337. It covers exactly this point.
If you don't do something like what is described there you run a risk of
getting into a situation where you can't get out of hold state.
Thanks,
Paul
On 10/14/11 1:28 AM, deepak bansal wrote:
Hi Tarun,
Please help on
On 9/19/11 11:24 AM, Iñaki Baz Castillo wrote:
2011/9/19 Worley, Dale R (Dale)dwor...@avaya.com:
Well, the behavior if they are used in Proxy-Require is specified,
but you should check the RFC to see whether it is supposed to be
used. E.g., the text in sip-parameters talks about using
I support what Dale says. For more info, see section 5.3 of RFC 6337.
Thanks,
Paul
On 9/15/11 4:59 PM, Worley, Dale R (Dale) wrote:
From: Sproul, Barry K [barry.spr...@verizonwireless.com]
I have an issue between 2 vendor platforms that causes permanent audio
on hold. Initial
On 9/12/11 12:03 PM, Francis Joanis wrote:
Hi,
Apologies if this has been answered before...
I have a question about when the BYE between the Transferor and the
Transferee is sent in the case of an unattended transfer.
RFC 5589 says in Section 6 that [the transferor] could emit a BYE to
On 9/9/11 1:27 AM, prakash k wrote:
Hi All,
I have the following scenario:
Incoming invite has Privacy:id along From header carrying Display Name
Where as the outgoing INVITE has From Header set
sip:Anonymous@Anonymous.invalid whereas the display-name goes as it is.
Is there any draft
On 9/9/11 2:56 AM, Abhishek Sahu wrote:
Hello All
I've one query regarding behavior of Record-Route. If Record-Route is present
in SIP unreliable 18x response and UPDATE needs to be sent prior to receiving
of 2xx response. So should the Route header for the UPDATE request be updated
On 9/9/11 11:11 AM, Wyne Wolf wrote:
Never mind guys. The server is locking the account to the IP address the
account was first used. I guess it was for security reasons. Thanks again.
Great! This server really doesn't get how SIP is supposed to work, and
what the point of registration is. If
On 9/5/11 12:23 AM, Tarun2 Gupta wrote:
Hi Salil
As per offer answer model, SDP in PRACK can be an offer as well as an answer.
Refer RFC 3262
and http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-18
for further details:
The latter is now RFC 6337 (finally!)
Thanks,
On 9/6/11 5:02 PM, sathish kumar chevuru wrote:
Hi,
In case of Call Transfer using 3pcc and REFER , If the Callee sends out
REFER without sending INVITE HOLD, What should be the behaviour of 3pcc.
Does 3pcc sends out INVITE HOLD's to Caller and Callee , before
initiating the call
On 8/11/11 12:53 PM, Iñaki Baz Castillo wrote:
2011/8/11 Kevin P. Flemingkpflem...@digium.com:
You are talking about two different things; it's completely possible for
a callee's end system to be registered, but for that person to be 'not
logged in' (and thus unavailable to receive calls).
On 8/11/11 3:00 PM, Iñaki Baz Castillo wrote:
2011/8/11 Paul Kyzivatpkyzi...@alum.mit.edu:
That contrasts with a case where the example.com server receives a
request for sip:al...@example.com and discovers that al...@example.com
is not in the location server, so that registrations for it could
On 8/4/11 5:02 AM, Iñaki Baz Castillo wrote:
Good point. I confirm that = after hvalue is mandatory and as per
RFC 3261 BNF, the following SIP URI is valid:
sip:qwe.com?qwe=qweasd=
while this one is not valid:
sip:qwe.com?qwe=qweasd
I've confirmed it using my SIP parser which is
On 7/27/11 8:29 AM, Leo Leo wrote:
Interesting, never thought about it. So, if I send a re-INVITE for
which I have no final reply yet and then I send a BYE, should the UAS
reply 200 for the BYE and terminate the remaining re-INVITE
transasction without sending a final response?
Or should the
On 8/3/11 1:48 PM, Iñaki Baz Castillo wrote:
2011/8/3 Paul Kyzivatpkyzi...@alum.mit.edu:
They BYE does *not* terminate all transactions!
Every transaction must follow its own state machine, independent of any
other transaction.
You MUST attempt to send some final response to any outstanding
+1 to what Bob says.
In addition, I suggest you read:
* RFC 5057 Multiple Dialog Usages in the Session Initiation Protocol
* RFC 5407 Example Call Flows of Race Conditions in the
Session Initiation Protocol
Thanks,
Paul
On 8/3/11 3:37 PM, Bob Penfield wrote:
It may
On 7/14/11 10:13 AM, Olle E. Johansson wrote:
14 jul 2011 kl. 16.11 skrev Iñaki Baz Castillo:
2011/7/14 Olle E. Johanssono...@edvina.net:
I assume it's just a private/custom vendor specification working on
its own devices (and just that).
No, many vendors use it. And if it was private,
.
Thanks,
Paul
Regards
Atul
--- On *Wed, 13/7/11, Paul Kyzivat /pkyzi...@alum.mit.edu/* wrote:
From: Paul Kyzivat pkyzi...@alum.mit.edu
Subject: Re: [Sip] Codec Negotiation and renegotiataion
To: s...@ietf.org
Date: Wednesday, 13 July, 2011, 10:31 PM
On 7/11/11 6:42 AM, Brett Tate wrote:
Is it OK to send a subsequent NOTIFY in a SUBSCRIBE initiated
dialog, before receiving a successful response for the earlier
NOTIFY request?
Yes; unless specifically restricted by the event package,
draft-ietf-sipcore-event-rate-control, or similar RFC.
Inline
On 7/7/11 11:10 AM, Saúl Ibarra Corretgé wrote:
Hi,
On Jul 7, 2011, at 3:19 PM, Paul Kyzivat wrote:
AFAIK there is nothing written specifically about this subject.
Some thoughts:
- when in doubt, the obvious thing to do is to offer whatever
you would have if you received
please ignore
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
On 7/1/2011 5:12 PM, Kevin P. Fleming wrote:
On 07/01/2011 02:24 PM, Worley, Dale R (Dale) wrote:
From: Johnson, Michael A [michael.a.john...@team.telstra.com]
The PBX (Mitel) that sends the re-invite without SDP, that then
accepts the offered G.729 codec from the ISP, despite not being
Please read
http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-18.txt, and
try to understand it before asking more questions like this.
I gave you this reference earlier. I'm pretty certain that all the
questions you have asked are dealt with there.
Thanks,
Paul
On
You will have to give more details before any sort of answer is
possible. Some things to specify:
- Does each account have a distinct phone number?
- what sort of peering is there between the carriers?
- how (if at all) is enum used by each carrier?
- what sort of enum are you talking about?
Of Paul
Kyzivat
Sent: Wednesday, June 22, 2011 10:13 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] no supported header in re-invite or
different value
Ravi,
- there is *no* semantic difference between a Supported header
that *doesn't* contain timer
notify the sender by
phone or email immediately and delete it!
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
Kyzivat
Sent: Tuesday, June 28, 2011 3:44 AM
To: sip-implementors
On 6/28/2011 6:46 PM, Nauman Sulaiman wrote:
Hi,
After OA is complete is it possible for UAS to send more 18x responses (with
no offer or answer of course).
YES.
UAC UAS
|INVITE--|
| |
|1xx (o)-| -
See http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-18.txt
Bottom line is:
If you returned answer in a reliable provisional response, you are
permitted to include a copy of that answer in the 200, but you are
encouraged to *not* do so.
The UAC must be prepared for it to be there.
Supported and Require are not formally linked.
For some options you can infer a logical connection.
When in doubt, be explicit.
Also note that Require:xyz means I require you to *support* xyz. It
does not mean I require you to *use* xyz or I intend to use xyz.
Thanks,
Paul
On
inline
On 6/24/2011 7:26 PM, Nauman Sulaiman wrote:
Hi,
Just wondering what is preferred here?
UA1 offers PCMU, PCMA, G729 (PCMU most preferred) to UA2
UA2 answers with PCMU
This completes OA and PCMU is negotiated codec
Then UA2 is put on hold and then unheld
you don't say what was
Ravi,
- there is *no* semantic difference between a Supported header
that *doesn't* contain timer and the total absence of a
Supported header.
- session-timer negotiation is repeated in every reinvite and
update. If it is not renegotiated to be on, then it is off.
So in both your
On 6/22/2011 12:40 PM, Nauman Sulaiman wrote:
Hi
Some UAs do not support PRACK or UPDATE and still work fine with various
Proxies, PBX, Softswitches etc. Are there any scenarios or well known
Proxies,Softswitches that require mandatory PRACK and UPDATE support for a UA
to be
On 6/9/2011 4:08 AM, Iñaki Baz Castillo wrote:
2011/6/9 Paul Kyzivatpkyzi...@cisco.com:
On 6/8/2011 3:50 PM, Iñaki Baz Castillo wrote:
Some existing proxies reply some custom 4XX codes for these kind of
errors. I would like some specific and standarized 4XX response code,
something like:
These are indeed fuzzy cases.
IMO, I would treat problems with a URI in a topmost Route header the
same as a problem with the R-URI when there is no Route header.
(So I think 416 is appropriate for case (d).)
The others don't seem to fit 416 or anything else very well.
So when in doubt, go with
On 6/8/2011 3:50 PM, Iñaki Baz Castillo wrote:
Some existing proxies reply some custom 4XX codes for these kind of
errors. I would like some specific and standarized 4XX response code,
something like:
467 Unsupported Transport
Go for it! Submit a draft. (Send it to the dispatch list.)
On 4/28/2011 3:01 AM, Nauman Sulaiman wrote:
Hi,
Scenario is as follows UAC makes call to UAS over Broadworks B2BUA and then
UAC goes on hold. Broadworks periodically issues Session Audit with SDP
version number unchanged, this is for UAC and UAS which do not support
session timers or
On 4/26/2011 1:09 PM, isshed wrote:
Thanks Dale for your response. so the other doubt is what will happed to
this dialog when the call gets transferred. does it not get destroyed with
the BYE? if so what about the rest of the notify?
You should read 5057 on dialog usages - you need to
On 4/12/2011 12:21 PM, Randell Jesup wrote:
3 apr 2011 kl. 13.23 skrev Iñaki Baz Castillo:
2011/3/31 Olle E. Johanssono...@edvina.net:
If you are sending only ringback, I would recommend sending 180 with SDP
instead of 183. If you're sending 183, I can't move my state machine to
ringing
Is this a trick question?
A *client* never sends responses. The thing that sends (any) response is
an server.
I guess the question is whether there is any case where a UA can send a 482?
Thanks,
Paul
On 3/30/2011 10:57 AM, Brett Tate wrote:
Is there any scenario or use case
On 3/30/2011 3:33 AM, Jyoti Singhal wrote:
Hi All,
In case if we have received 200 OK to an INVITE request, now due to same
failure at proxy, proxy wants to end the call --- What should be the
scenario?
Your case below isn't clear. I presume there is a proxy in the middle
that isn't
This thread has gone on for a long time. There is some good/accurate
info and some very wrong info here. This is a complex topic that is
widely misunderstood. I *strongly* encourage you to read the
offer-answer draft referenced earlier. It is a compilation of
information from multiple RFCs and
On 3/1/2011 6:03 AM, Nikos Leontsinis wrote:
I am not sure if implementors are obliged to honour this request.
Implementors are obliged to honor whats written in specs if they want to
claim compliance to the spec, and to interoperate with other compliant
implementations.
If you don't care
...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat
Sent: Thursday, February 10, 2011 5:26 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Query on Handling of null ipv6 address
in SDP c= line.
Adding to what brett said...
Why is it necessary to have a separate null address
Adding to what brett said...
Why is it necessary to have a separate null address for IPv6?
Null is null. Won't an IPv4 null address do? Even if your node doesn't
support IPv4, I would think it could support a *null* IPv4.
Thanks,
Paul
On 2/7/2011 7:09 AM, Brett Tate wrote:
I agree with Dale and Brett, sort of.
Brett is right that the UAC is correct in ignoring the change in the
200. Dale is right that the UAS is wrong in sending different SDP in the
180 and 200.
See http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt
Thanks,
Paul
On 1/31/2011 6:06 PM, Mikko Lehto wrote:
I fail to understand why DTMF delivery methods in signaling path are not as
stabilized as RFC 2833/4733 is.
There are many use cases where nice features can be enabled with events
while dedicated event detector is not feasible in media path.
On 1/19/2011 4:13 AM, Sunil wrote:
Hi All,
Please clarify how to handle the below requirement of rfc 3261in case of
3 scenarios: The UAS MUST ensure that the session description overlaps
with its previous session description in media formats, transports, or
other parameters that require
Also, the following from the description of 488:
A message body containing a description of media capabilities MAY be
present in the response, which is formatted according to the Accept
header field in the INVITE (or application/sdp if not present), the
same as a message body in a
Sunil,
Its not clear to me if you have a question for sip-implementors, or a
question for IMS-implementors.
The reg event package provides a way to monitor the status of *all* the
registrations for a particular AoR. The fact that a UA has unregistered
itself (or been unregistered) does not
On 1/13/2011 10:38 AM, Iñaki Baz Castillo wrote:
2011/1/13 Olle E. Johanssono...@edvina.net:
- Does your UA add an SDP to a 488 error message?
Most probably no UA in the world adds SDP to a 488 response.
I don't know, but I suspect you are right, or nearly so.
And for sure, no UA in the
,
Paul
On 1/8/2011 9:08 AM, Kevin P. Fleming wrote:
On 01/07/2011 09:47 PM, Paul Kyzivat wrote:
On 1/7/2011 9:21 PM, SIP Satan wrote:
Cant we play multiple announcements by giving different SDP's in
multiple 1xx responses provided
each 1xx carries a different To-tag. In a way simulating forking
forking.
That of course assumes that the UAC is capable of rendering media from
different early dialogs.
Thanks,
Paul
Regards
-Satan
On Fri, Jan 7, 2011 at 8:42 PM, Paul Kyzivat pkyzi...@cisco.com
mailto:pkyzi...@cisco.com wrote:
inline
On 1/7/2011 12:10 AM
Its not really a responsibility of the recipient to check this, at least
in straightforward cases. How would it know that the proxy has been
bypassed? If the request arrives, and has the correct form, then I would
expect the UAS to process the request. To detect the problem it would
have to
Look at the offeranswer draft for a discussion of this.
While your option 1 will work in some cases, it won't always work.
Specifically, if both sides put the call on hold, then there will be no
way to get off hold.
The solution is to always offer the directionality your end wants,
without
IMO, if a UA is given a URI to call, it generally has no business
messing with it in any way. Removing the port is altering the URI, and
should only be done by something in the domain of the URI that is
familiar with the policies for construction of URIs within that domain.
If the UA is
On 11/29/2010 11:06 AM, Alex Balashov wrote:
On 11/29/2010 10:44 AM, Ali Kemal MAYUK wrote:
I am investigating about how Centrex work with SIP. If an enterprise
customer has a 2 different locations, how they call each other with short
numbers(4 digit) ? Which SIP headers are used for it? Is
We rarely revise RFCs solely to clarify the wording. Sometimes we issue
clarifying RFCs instead. Or the clarification is simply captured as an
errata and then it will be incorporated if/when the RFC is revised.
Thanks,
Paul
On 11/29/2010 11:20 AM, Iñaki Baz Castillo wrote:
It would seem that your ACK isn't being recognized as matching the
INVITE. Without details can't say if the fault is with the UAC or UAS.
What's needed to sort it out is the INVITE, 200, and ACK messages.
Thanks,
Paul
On 11/19/2010 4:16 PM, Wyne Wolf wrote:
Hi all,
I am new
I agree with Dale, with an added comment
On 11/19/2010 5:04 PM, Worley, Dale R (Dale) wrote:
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Tarun2 Gupta
[tarun2.gu...@aricent.com]
On 11/11/2010 2:19 PM, meena singla wrote:
Hello,
As P-CSCF does not maintain any data regarding GRUU during registration. When
P-CSCF receives an INVITE request and its Con tact header contains only
temp-gruu. How the P-CSCF will process that request?? How P-CSCF will relate
that
The URI you use in the Contact for requests and responses can be
anything that works for you. It need not have any relationship to the
contact you registered. However, if you receive a request that was
addressed to your AOR and routed to you via your registered contact,
then the contact you
I don't know one offhand, but I'm quite certain there are some that do.
Hopefully they will speak up.
Paul
On 11/11/2010 1:46 PM, SIP Satan wrote:
Paul,
Is there any server which supports gruu , along with its reg-event
package extension ?
Regards
-Satan
On Thu, Nov 11, 2010 at
An UPDATE is an UPDATE. The effect is strictly a function of its
content. And as already mentioned, every UPDATE either refreshes the
session timer, or disables it, regardless of what else it does.
I suppose you might consider that an UPDATE that does nothing else must
have been intended only
There are a number of headers that may only appear once, including From,
To, CSeq. IIRC this is addressed in the text relevant to each one.
Thanks,
Paul
On 11/9/2010 1:27 PM, SungWoo Lee wrote:
Dear,
Does 3261 specify the number of a certain header in a SIP message? We know
One more thing...
If you are encountering problems like this, it suggests that you are
building a new sip stack from scratch. If so, you should realize that
this is not a small task, and it will likely take you a lot of time and
effort to get it right. You should seriously consider reusing
and a lot of time
debugging your result.
Good luck,
Paul
Nahum
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
Kyzivat
Sent: Thursday, November 04, 2010 6:11 PM
To: sip
I *think* you have gotten a valid response from other respondents, but
I'm not certain about the question. You say the terminating party
supports 100rel, but does the originating party indicate support for
100rel? That is a necessity to use reliable provisionals.
The thing you want to read is
at end
On 10/28/2010 4:23 PM, Worley, Dale R (Dale) wrote:
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of kaiduan xie
[kaidu...@yahoo.ca]
Consider the following case, A sends an
I suspect as time goes on people are losing the concept of multiple
devices sharing the same AOR.
Thanks,
Paul
On 10/23/2010 7:38 AM, Iñaki Baz Castillo wrote:
2010/10/22 Hazzyhazzy...@yahoo.co.in:
The RFC 3680 states that a single NOTIFY can have details of multiple
The subscription, to an AOR, should give info about registrations for
that AOR. In principle it can give information about other AORs too.
The only place I know of that uses that is 3gpp/ims. In IMS, a
subscription to the reg event package for an AOR gives you status on
that AOR and all
Sorry about that. I remembered the wrong number.
Thanks,
Paul
On 10/1/2010 6:02 PM, Worley, Dale R (Dale) wrote:
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
goutam,
This situation is discussed in section 5.3 of:
http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt
More inline
On 9/22/2010 5:45 AM, goutam kumar wrote:
Hi,
I'm trying to implement a VOIP call between two endpoints. I'm in a doubt.
Say Alice and Bob are in a call.
Inline
On 9/22/2010 7:18 AM, abhishek chattopadhyay wrote:
Hi Implementors,
In 3261 the re-transmission of INVITE is stopped by 1xx responses. So to
stop the re-trnasmission of 200 OK, ACK is sent.
(Albait it would be worth considering that ACK is used for a lot of other
purposes.)
On 9/17/2010 7:45 AM, anand madhab wrote:
Hi, If m line is missing in invite request and 180, 200 response then what
will be senario ?
I dont understand the case, I mean i want to make a call with initially
putting a person in hold ? please explain
does caller need to reject the call
Your
Lakshmi,
This is an inappropriate list for this question.
I suggest you take it to sip-implementors.
Thanks,
Paul
Vijayalakshmi wrote:
Hi,
Iam trying to develop a SIP server in VxWorks. Please assist me
with how to implement SIP in my Server. Where do I get these
Iñaki,
IMO you should not use CSeq this way, for a variety of reasons:
- its a layer violation. The cseq values are pertinent at the
dialog layer. The content of the NOTIFYs is at the application
layer.
- if perchance the dialog is being used for something else
(e.g. an INVITE) as well
Another possibility is that dropping messages with long lines is an
explicit policy of the ALG, rather than just being a crappy
implementation. If so, then the responsibility lies with whoever set the
policy.
Thanks,
Paul
Paul Kyzivat wrote:
Iñaki Baz Castillo wrote:
Hi
Eduardo Martins wrote:
Hello, trying to clarify thoughts with early dialog forking, generally
is there such concept?
For instance when receiving two 180s with different tags, should:
a) 2 early dialogs be constructed (why? is there any need to a
REQUEST to be sent before receiving 2xx
Siddhardha Garige wrote:
Hello all,
I have a specific requirement to route REGISTER requests through a set a
predefined proxies to REGISTRAR. Can we configure UAs with this information
and generate a REGISTER request with Proxy1 and Proxy2 in route headers.
RFC 3068 SIP extension
Nitin Kapoor wrote:
Thanks for your reply.
I checked the RFC and noticed that it does not limit the codec #s in mline,
but nor does it comment on infinite number of codecs support being
mandatory.
So could you please let me know whether it is mandatory to support them or
not. Because
401 - 500 of 926 matches
Mail list logo
