Hi,
Any idea about currently how many live deployments are happening for
Sigcomp?
Does the Importance of it really going down with high bandwidth
availability?
rgds,
Prince
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https
As mentioned here SIP does not provided in itself billing related
mechanism,
however all the information necessary is at hand. Usually the B2BUA would
gather
the critical information to formulate a Call Detailed Record that is to be
sent to an external
machine. This is normally done via some sta
IMHO,
First what seems to be really strange in your description below is the
amount of 200 OK transmitted within 500 milli-seconds ( 7 times ).
This implies that either you hav choosen a really low value of T1 and T2
timer or you are not complying with protocol recommendation w.r.t to
retransmitt
As part of a research project, we are working on automated diagnostics
of network-related faults in VoIP systems. If you have observed errors
that were hard for a lay person to diagnose, whether due to end system
problems, proxy idiosyncrasies, NATs, LAN or Internet issues, please
send me a
You may also like to see IMS 3GPP specifications on billing TS 22.115,
TS 32.240, TS 32.260 to get some more idea.
On Mon, Apr 27, 2009 at 7:56 AM, Manish Kambdur
wrote:
> Hi Nabam,
>
> No charging/billing messages are defined by the SIP protocol, which implies
> that the application is respons
It is the UAS who is creating the non-standard answer, in which case,
there is no way the UAC can send 4xx response.
Also, I do see a common codec which are iLBC and telephone-event. The
callee should have used the same dynamic payloads for these codecs as
in offer, but it chose difference ones. In
Hi Nabam,
No charging/billing messages are defined by the SIP protocol, which implies
that the application is responsible for the billing.
That is, SIP does not specify any methods for billing, and you are 'free to
choose' and implement any application specific billing solution you need.
Most of
Dear Folks,
Thank you for useful responses.
Please clarify one more query.
In case, Both side(caller & callee) call is established and RTP(Both side
iLBC) also flowing successfully but one side audio is coming and the other side
audio is not coming.
so what would be the problem(Ot
Hi Iñaki Baz Castillo,
Could you elaborate what does "SIP is not "designed" for billing" mean? I mean
there must be some way to do billing on SIP call otherwise how service provider
or vendor will get revenue. I understand that one way is by specified duration
such as monthly, yearly etc.
In
415 is often confused with 488.
"415 Unsupported Media Type" is what you would use if if didn't understand
the SIP message body content.
488 (which is similar to 606) would be a more suitable response:
21.4.26 488 Not Acceptable Here
The response has the same meaning as 606 (Not Acceptable),
Yeah, that is even better .. .what I thought was since CALLEE had already
replied not-in-protocol-way, CALLER may terminate the dialog.
Somesh
-Original Message-
From: ext Peter Nijhuis [mailto:peter.nijh...@televersal.com]
Sent: Monday, April 27, 2009 7:00 PM
To: Shanbhag, Somesh (NSN
I think Callee should respond with 415 unsupported media type, since it is not
supporting media types 102, 0, 8 or 106.
Met vriendelijke groet, with kind regards, mit freundlichen Gruß
Peter Nijhuis
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mai
2009/4/27 nabam serbang :
> Hi,
> Could some one tell me how billing is done is SIP? Any call flow example
> would highly be appreciated.
SIP is not "designed" for billing. Also billing is too much complex
and wide to try to explain it in an unique way.
Basically billing can be done in a gateway
The basic thing is CALLEE has to take the subset of codecs offered by CALLER
and reply back.
But in your case, CALLEE is replying with different set of codecs (97 101) in
reply to CALLER codecs ( 102 0 8 106 )
IMHO, since the capabilities mis-match, immdiately end the call using BYE /
CANCEL wh
Thanks Amith,
In response to your comments:
In case of FE NAT, not only the source address of the peer may be
changed but also the IP address in the c-line of the SDP is meaningless,
so this is a different story and different handling. However if there is
a SBC or ALG in between (even in case of
Thanks Rastogi, but I can not accept your point - the IP address in the
C-line is related to the media stream. The only question is if it must
be symmetrical (especially assuming no NAT in between).
Regards
---
Meir Leshem
Veraz Networks
Tel: +972-3-9709107
Fax:
Hi,
I have a question regarding the IP address in the C-line of the SDP
message (RFC 4566).
The main purpose of the IP address in the C-line in the SDP message is
to indicate to the peer to what IP address it should send its RTP
packets.
However, my question is related to the RTP packets rece
Comments inline.
- Original Message -
From: Meir Leshem
Hi,
I have a question regarding the IP address in the C-line of the SDP
message (RFC 4566).
The main purpose of the IP address in the C-line in the SDP message is
to indicate to the peer to what IP address it should send its RTP
Dear Folks,
I have doubt in the following scenario.
Caller's sdp :
v=0
o=- 1234 1 IN IP4 10.10.20.35
s=-
c=IN IP4 10.10.20.35
t=0 0
m=audio 12000 RTP/AVP 102 0 8 106
a=rtpmap:102 iLBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 telephone-event/8000
Callee's negotiated
Hi,
I have a question regarding the IP address in the C-line of the SDP
message (RFC 4566).
The main purpose of the IP address in the C-line in the SDP message is
to indicate to the peer to what IP address it should send its RTP
packets.
However, my question is related to the RTP packets receive
In 3GPP specs, related to IMS procedure, it's written that P-CSCF sends
the SUBSCRIBE request to I-CSCF which in turns finds the address of
S-CSCF through Cx query. My question is why can't P-CSCF send the
SUBSCRIBE directly to S-CSCF using Service-Route it received during
Registration.
Dushy
21 matches
Mail list logo
