After the initial offer/answer is complete, your PBX can eventually 'lock'
the actual codec to be used by sending an updated offer back to X-lite.
RFC 3264 Section 10.2 discusses this scenario in detail.
Nonetheless, your PBX should be willing to accept any payload type signaled
in the codec list
http://www.ietf.org/rfc/rfc4916.txt
~Vikram
On Thu, Apr 2, 2009 at 9:48 PM, junpark wrote:
> Hi,
>
> Does anyone knows how to change display information on the calling party
> phone?
>
> This is the scenarios that I'm concerned.
> *Alice calls Bob thru IP PBX.
> The call, however, is routed to
Fundamental thing is PBX must be able to decode the PCMA as well because
its fair to switch between the negotiated codecs of both the parties.
Since, PBX already knows that X-Lite can send PCMA any point of time, it
*must* be prepared to receive it as well.
Thanks,
Somesh
* Please donot take the
Hi,
Does anyone knows how to change display information on the calling party
phone?
This is the scenarios that I'm concerned.
*Alice calls Bob thru IP PBX.
The call, however, is routed to Carol in some reasons, and IP PBX wants to
let Alice is aware of this informaton..
1. Alice dialed to Bob
I agree with Ranjit/ ibc. This can be observed in various IPPBX which
responds the SUBSCRIBE with 403 Forbidden when event is recognized but not
supported for specific users (subscribers) due to limitation of resources
etc.
Best Regards,
Vivek Batra
Message: 5
Date: Thu, 2 Apr 2009 12:36:
Dale Worley wrote:
> On Mon, 2009-03-30 at 12:35 +0100, Stephen Paterson wrote:
>> I'm currently implementing RFC 3265 as an abstract layer upon which our
>> customers can build their own event packages and I'm trying to determine
>> exactly what information their applications will need in order
Dear all,
I think many of you already experienced this issue when using X-Lite.
When my pbx offers with a codec preference of PCMU and PCMA,
X-Lite answers back with the same codec preference of PCMU and PCMA.
So, at this point, both X-Lite and my pbx know each other's preference,
and it is the
On Mon, 2009-03-30 at 16:46 +0200, Iñaki Baz Castillo wrote:
> Hi, I've a PBX acting also as dialog presence server. Users are not
> local, they exist in a proxy in front of the PBX.
>
> When the PBX (a B2BUA) sends an "INVITE sip:al...@domain" to the
> proxy, the PBX inmediately sends a NOTIFY to
On Mon, 2009-03-30 at 12:35 +0100, Stephen Paterson wrote:
> I'm currently implementing RFC 3265 as an abstract layer upon which our
> customers can build their own event packages and I'm trying to determine
> exactly what information their applications will need in order to
> support any possible
On Fri, 2009-03-27 at 15:14 +0530, Anuradha Gupta wrote:
> My query is that on receiving 380 response, what should be the
> possible handling
> 1. Terminating the call and initiating new request for alternate
> service after interpreting the message body.
> 2. Redirecting the Call request to re
+1
Michael Procter wrote:
> Scott Lawrence wrote:
>> On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
>>> Hi all,
>>> Thanks for your replies. Lots of answers saying I'll only get a single
>>> 200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
>>> get my meaning.
>>
>>The registrar is non-conforming. It should have failed the request since
Yes, absolutely.
My reaction was just because the behaviour was so ridiculous.
"SIP in action!!" is just my sarcastic/satirical exclaimation - stuff in the
real world
doesn't do even the most basics of checks!!
* sigh
Attila Sipos wrote:
> Would you believe it? I tried it out and I got:
>
> 5) the proxy adds Path and adds Requires:path.
>The registrar doesn't support it, doesn't copy the Path and doesn't
> use it.
>
>
> Welcome to SIP in action!!!
I can't tell if you are happy, or what.
The registrar
Oh and before anyone corrects me,
I actually used "Require: path" (not Requires as written in the e-mail)
-Original Message-
From: Attila Sipos
Sent: 02 April 2009 16:01
To: 'Paul Kyzivat'
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] What's the harm in al
Would you believe it? I tried it out and I got:
5) the proxy adds Path and adds Requires:path.
The registrar doesn't support it, doesn't copy the Path and doesn't
use it.
Welcome to SIP in action!!!
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: 01 Apr
Scott Lawrence wrote:
> On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
> > Hi all,
> > Thanks for your replies. Lots of answers saying I'll only get a single
> > 200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
> > get my meaning.
> > Anyway, just to finish off,
I may be getting my terminology slightly wrong. Some event packages
allow only the first dialog to create a subscription, or at least
RFC3265 allows for this. If this is the case for any given package, all
subsequent NOTIFYs on different dialogs are then to be rejected. I see
no reason why I should
On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
> Hi all,
> Thanks for your replies. Lots of answers saying I'll only get a single
> 200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
> get my meaning.
> Anyway, just to finish off, I'll be adding a flag so that the
Unfortunately the 403 is often ambiguous concerning what is forbidden, for how
long, and in what situation. For instance, is SUBSCRIBE forbidden or only the
Event's option-tag forbidden?
Concerning the original question, returning 489 makes since if able to indicate
events supported for user.
2009/4/2 Avasarala Ranjit-A20990 :
> No there could be a case like u support the event - so u recognize it. But u
> do not want to accept the subscriptions for it. So u send 403.
For me 403 means that "I support it but not for you".
--
Iñaki Baz Castillo
_
If UA2 is capable of the other things you mention then maybe 488 is
suitable (since there are other options)
>>But if we send 500 it means UA2 is not able to handle any call
currently, which is not true.
it is true if it can't make the alternative calls you describe - so 500
would be correct i
If you don't want to accept subscriptions for an event, then that means you
don't support it.
If you reconfigure your system to accept subscriptions for an event then you do
support it.
"Support" means that the system can do it at the time of the request in its
current state.
It is not the sam
No there could be a case like u support the event - so u recognize it. But u do
not want to accept the subscriptions for it. So u send 403.
Regards
Ranjit
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] O
2009/4/2 Avasarala Ranjit-A20990 :
> As per RFC 3265, if u recognize an Event, u support it. But if an event
> is recognized and not supported, 403 Forbidden may be appropriate
I don't see the difference between "recognized" and "not supported".
For me it means the same. If a UAS doesn't support a
As per RFC 3265, if u recognize an Event, u support it. But if an event
is recognized and not supported, 403 Forbidden may be appropriate
Regards
Ranjit
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Beha
Hi all,
Wondering what should be the appropriate response to a SUBSCRIBE received with
a recognized but unsupported Event. As far as I can see, the RFC talks of only
responding with 489 to unrecognized events.
Any thoughts?
Regards,
Rohit
Add more friends to your messenger and enj
What if UA2 wants to chat with UA1 over MSRP or chat with sharing video
like yahoo chat (with webcam without microphone)? I think without sound
card UA2 can still support these kind of calls. But if we send 500 it
means UA2 is not able to handle any call currently, which is not true.
Dushyant P
But the client may still get NOTIFYs from multiple servers, each of which
creates a dialog.
4.4.9. Handling of forked requests
Each event package MUST specify whether forked SUBSCRIBE requests are
allowed to install multiple subscriptions.
...
If installing of multiple subscriptions by
Iñaki Baz Castillo wrote:
> 2009/4/2 Stephen Paterson :
>
> > Anyway, just to finish off, I'll be adding a flag so that the user can
> > say whether they want to accept multiple dialogs or not.
>
> Not possible. A proxy doing forking for a SUBSCRIBE (non-INVITE
> transaction) will just accept the f
Dear Friends,
Thanks for your valuable respnses.
I plan to send 500 "No Soundcard". Because in my case no problem in SDP. so 500
is the best response from UA2.
Thanks & Regards,
Vijay
--- On Thu, 2/4/09, Attila Sipos wrote:
From: Attila Sipos
Subject: Re: [Sip-implementors] Error R
2009/4/2 Stephen Paterson :
> Anyway, just to finish off, I'll be adding a flag so that the user can
> say whether they want to accept multiple dialogs or not.
Not possible. A proxy doing forking for a SUBSCRIBE (non-INVITE
transaction) will just accept the first 200 Ok and drop the rest. So
the
Hi all,
Thanks for your replies. Lots of answers saying I'll only get a single
200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
get my meaning.
Anyway, just to finish off, I'll be adding a flag so that the user can
say whether they want to accept multiple dialogs or not. The
I guess 603 Decline would work in this case. One can also go for 487 Request
Terminated.
Regards,
Srikant
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Attila
Sipos
Sent: Thursday, April 02,
I'd agree on this.
415 means it doesn't understand sdp (not true)
488 means it didn't agree codec selection (not true)
488 also, to me, also implies that some other codec might work (not true)
If there are no other sound cards, then I'd agree that
500 is more suitable that 415 or 488:
21.5.1
34 matches
Mail list logo
