method.
In the case of UDP, the message might be fragmented over multiple UDP packets,
and in the case of TCP/IP, one TCP datagram could contain more than 1 SIP
message.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.124
ine the length of the
strings they are passing, then maybe they should find another line of work ;) I
totally agree that simplicity is great, but probably not at the risk of Access
Violations.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT
approximations, but you have to consider that the standard does not impose any
limit on these either. I would say the user of your API should be the one
cognizant of lengths, and provide them to your API appropriately.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
I'd have to dig up the RFC for PRACKs to comment on that. If the problem is at
that level though, I don't believe that a 481 response is quite right.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Origin
Do the Request-URIs line up?
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
I would take a look at the contact header in the INVITE and both PRACKs.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip
Your last point is something I overlooked mentioning. Yes, even with media
negotiated, if it's not sent then intent should be derived from something else
(previous 180 Ringing for example).
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastli
adata included within the headers.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Beha
statements.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: Brett Tate [mailto:br...@broadsoft.com]
Sent: March-27-15 10:03 AM
To: Joel Gerber; sip-implementors
Subject: RE: [Sip-implementors
would have saved a lot of headaches.
Joel Gerber
Network Operations Specialist - Telephone
Telephone
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On B
It is not mandated either way. It could be sent at any interval between the
last UPDATE/INVITE and 100 seconds. I believe it is recommended, and standard
practice follows, that half-life is when to send it out, but it is not required.
Joel Gerber
Network Operations Specialist - Telephone
hat Henning Christiansen is,
that the packet capture that received the RTP event (the IVR) might be missing
some signaling information. Did you have to "Decode As" the RTP packets in the
last hop? If so, did you "Decode As" RTP instead of RTP event?
Joel Gerber
Network Sp
RFC 3325/3324. I don't think this scenario is directly mentioned, because it's
silly, but it's valid according to the ABNF.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message-
From: sip-im
It's valid, but more than slightly silly. Why even send a PAID if it's not
going to have valid information?
For PPID, it still would be valid, but pretty much guaranteed that it will be
ignored.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eas
Wow, thanks for sharing. I honestly didn't know about that one!
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message-
From: Hadriel Kaplan [mailto:hadriel.kap...@oracle.com]
Sent: July-18-13 1:48 PM
To: Joel G
is both allowed, and maybe even expected.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: July-18-13 11:11 AM
To: ikuzar RABE
Cc: sip-implementors@lists.
ot;standard", as it isn't specified in the ABNF
for SIP/2.0. Because of this, I would recommend sending out no more than 256,
but allowing as much as your software can safely buffer.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1
t necessarily having to translate on all of the
digits.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: July-16-13 3:27 PM
To: Joel Gerber
my carrier interconnects.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: July-16-13 11:39 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [
, as it is acting as a UAS and a
UAC for the same dialog.
Joel Gerber
Network Administrator
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca<mailto:joel.ger...@corp.eastlink.ca> T:
519.786.1241
From: SIP Learner [mailto:rfc3...@foxmail.com]
Sent: July-16-13 10:46 AM
To: Joel Gerbe
I know Genband's C20/CS2000 switches support (and default) to using the INFO
method for overlapping digits (this is what they call partial dialled digits
followed by subsequent digits).
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786
A lot of the time you wouldn't be able to find out that a wrong number was
dialled until all of the digits were collected.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message-
From: SIP Learner [mailto
as possible. Because of this, it is much
easier to implement nifty new features. At the same time, it makes interop more
of a challenge ☺
Joel Gerber
Network Administrator
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca<mailto:joel.ger...@corp.eastlink.ca> T:
519.786.1241
Fro
ntage that I can see in a modern trunking network of
initially sending a subset of the total digits to be dialed.
Joel Gerber
Network Administrator
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca<mailto:joel.ger...@corp.eastlink.ca> T:
519.786.1241
From: Cary FitzGerald [mail
That's an awesome question. To be honest; I'm not sure of when it's even a good
idea in a TDM network. The time you save in routing lookups is negligible in an
ISUP network. Maybe during the days when MF was king it made more sense?
Joel Gerber
Network Specialist
Network Operat
One more note; you could have a multi-part message body with different
charsets. So 6556 and 78788 could be in one part as ASCII, while testname would
be in another part as UTF-16.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
your Contact header would read as
`Contact:
` and
your Request-URI would read as `INVITE
sip:otherparty;tgrp=trkgrpa;trunk-context=google....@google.com SIP/2.0`.
Joel Gerber
Network Administrator
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca<mailto:joel.ger...@corp.eastlink.
you're
interconnecting with. I have encountered some equipment that ignores the trunk
group information specified in the R-URI and only honour what is located in the
Contact header, so MMV.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786
LNP
information, to Disconnect Reason Codes, ...
It's annoyed me so much that I've started dropping SIP-T/SIP-I for my
interconnects and have been reverting to pure SIP. I've found compatibility
with a lot of soft-switch vendors is actually improved in this scenario.
Joel
has occurred. Then,
ideally, it should couple this knowledge with the identical timestamp header
present in all of the E bit packet's RTP headers in order to decide that it
should accept these packets as related to the same event, even though they
don't seem to follow RFC.
Joel Gerb
against the standard as interpreted by myself, the receiver
should be able to deduce that they belong to the same event. The 9th paragraph
in 2.5.2.2 also reiterates this point.
I hope this helps. I should also note that you can't send attachments to this
list. Hopefully my detailed de
both form the
complete RTP flow for a specific call. If you neglect the UDP port information
you could potentially be looking at a completely different RTP flow than the
one intended.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786
can be located in different messages, or
even modified partway through a dialog (phone call.)
RFC 6337, 3264 and 4566 can provide a lot more information on this.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Original Message
arer path works, and can handle simultaneous calls without
quality issues.
7. Also do tests for any other call features that you might be making available
on the SIP trunk link.
Joel Gerber
Network Specialist
Network Operations
Eastlink
E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-Origina
hat it's involved with
an existing dialog, and hence can be then identified as a Re-INVITE. See RFC
3261 Section 14 for more details.
I hope this information proves to be helpful;
Joel Gerber
Eastlink
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-im
be a good reference, and that's actually a Proposed
Standard.
I believe the ITU-T SIP-I specification has the most details on encapsulated
ISUP, I just don't have it on my computer right now.
I hope this helps;
Joel Gerber
From: Vivek Singla [mailto:vivsin...@yahoo.com]
Sent: Decem
ch is notorious for only sending the IAM in the INVITE, and doesn't
give any other ISUP message bodies through the progression of the dialog. YMMV
:)
Joel Gerber
Eastlink
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.co
laces a 255
character limit on the URI itself, but doesn't mandate this, just lists it as a
best practice (Section 3.2.1).
Joel Gerber
Network Specialist
Network Operations
Eastlink
joel.ger...@corp.eastlink.caT: 519.786.1241
-Original Message-
From: sip-impleme
38 matches
Mail list logo
