16 Aug
2007
16 Aug
'07
3:06 p.m.
There is now a Grandstream GXV3000 in my network (neat little
videophones, I must say).
However, when someone sends a presence event through my server, the
grandstream responds with a SIP packet and additional XML info:
U 99.101.102.103:5060 -> 172.17.240.240:54330
NOTIFY sip:1101XXXXXXX@172.17.240.240:54330 SIP/2.0.
Record-Route: <sip:99.101.102.103;ftag=f0a1719429e37564;lr=on>.
Via: SIP/2.0/UDP 99.101.102.103;branch=z9hG4bK4204.13bfa134.0.
Via: SIP/2.0/UDP 66.69.71.90:34202;branch=z9hG4bK04c43fa29c41b774.
From: <sip:1101ZZZZZZZ@proxy.ourdomain.com>;tag=f0a1719429e37564.
To: "Jessa"<sip:1101XXXXXXX@proxy.ourdomain.com>;tag=1b55e40b.
Contact: <sip:1101ZZZZZZZ@66.69.71.90:34202>.
Call-ID: ZjczZGMzOWEzMTk0NjhkMzRjMjI3ODZkNzIwMGIxZDA..
CSeq: 1843 NOTIFY.
User-Agent: Grandstream GXV3000 (HW 0101, Ch:0) 1.0.1.7.
Max-Forwards: 16.
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK.
Event: presence.
Subscription-State: active.
Content-Type: application/xpidf+xml.
Content-Length: 342.
P-hint: LR.
.
<?xml version="1.0"?>.
<!DOCTYPE presence.
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">.
<presence>.
<presentity
uri=""Jessa"<sip:1101XXXXXXX@proxy.ourdomain.com>;tag=1b55e40b;method=SUBSCRIBE"
/>.
<atom atomid="1000">.
<address uri="<sip:1101ZZZZZZZ@66.69.71.90:34202>">.
<status status="open" />.
</address>.
</atom>.
</presence>
The XML info is causing errors in the logs (which I've been ignoring for
now, but that's not really an optimal solution).
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_to : unexpected char [>]
in statu
s 4: <<<>> .
Aug 15 15:16:12 proxy ser[19620]: ERROR: get_hdr_field: bad to header
Aug 15 15:16:12 proxy ser[19620]: ERROR:maxfwd:is_maxfwd_present :
parsing MAX_F
ORWARD header failed!
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_uri: uri too short: <> (0)
Aug 15 15:16:12 proxy ser[19620]: is_user_in(): Error while parsing URI
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_to : unexpected char [>]
in statu
s 4: <<<>> .
Aug 15 15:16:12 proxy ser[19620]: ERROR: get_hdr_field: bad to header
Aug 15 15:16:12 proxy ser[19620]: find_first_route: Error while parsing
headers
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_uri: uri too short: <> (0)
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_sip_msg_uri: bad uri <>
Aug 15 15:16:12 proxy ser[19620]: WARNING: do_action:error in expression
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_to : unexpected char [>]
in statu
s 4: <<<>> .
Aug 15 15:16:12 proxy ser[19620]: ERROR: get_hdr_field: bad to header
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_to : unexpected char [>]
in statu
s 4: <<<>> .
Aug 15 15:16:12 proxy ser[19620]: ERROR: get_hdr_field: bad to header
Aug 15 15:16:12 proxy ser[19620]: find_credentials(): Error while
parsing header
s
Aug 15 15:16:12 proxy ser[19620]: pre_auth(): Error while looking for
credential
s
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_to : unexpected char [>]
in statu
s 4: <<<>> .
Aug 15 15:16:12 proxy ser[19620]: ERROR: get_hdr_field: bad to header
Aug 15 15:16:12 proxy ser[19620]: ERROR: parse_to : unexpected char [>]
in statu
s 4: <<<>> .
Aug 15 15:16:12 proxy ser[19620]: ERROR: get_hdr_field: bad to header
Aug 15 15:16:12 proxy ser[19620]: ERROR: build_res_buf_from_sip_req:
alas, parse
_headers failed
Aug 15 15:16:12 proxy ser[19620]: pre_auth(): Error while sending 400 reply
Other than forwarding presence information to a presence-capable server
that understands the XML, is there anything I can do on the SER side to
ignore the XML stuff so I don't get a screen full of error messages
every time a presence event comes through?
N.
16 Aug
16 Aug
3:13 p.m.
SIP wrote:
There is now a Grandstream GXV3000 in my network (neat
little
videophones, I must say).
However, when someone sends a presence event through my server, the
grandstream responds with a SIP packet and additional XML info:
U 99.101.102.103:5060 -> 172.17.240.240:54330
NOTIFY sip:1101XXXXXXX@172.17.240.240:54330 SIP/2.0.
Record-Route: <sip:99.101.102.103;ftag=f0a1719429e37564;lr=on>.
Via: SIP/2.0/UDP 99.101.102.103;branch=z9hG4bK4204.13bfa134.0.
Via: SIP/2.0/UDP 66.69.71.90:34202;branch=z9hG4bK04c43fa29c41b774.
From: <sip:1101ZZZZZZZ@proxy.ourdomain.com>;tag=f0a1719429e37564.
To: "Jessa"<sip:1101XXXXXXX@proxy.ourdomain.com>;tag=1b55e40b.
Contact: <sip:1101ZZZZZZZ@66.69.71.90:34202>.
Call-ID: ZjczZGMzOWEzMTk0NjhkMzRjMjI3ODZkNzIwMGIxZDA..
CSeq: 1843 NOTIFY.
User-Agent: Grandstream GXV3000 (HW 0101, Ch:0) 1.0.1.7.
Max-Forwards: 16.
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK.
Event: presence.
Subscription-State: active.
Content-Type: application/xpidf+xml.
Content-Length: 342.
P-hint: LR.
.
<?xml version="1.0"?>.
<!DOCTYPE presence.
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">.
<presence>.
<presentity
uri=""Jessa"<sip:1101XXXXXXX@proxy.ourdomain.com>;tag=1b55e40b;method=SUBSCRIBE"
/>.
<atom atomid="1000">.
<address uri="<sip:1101ZZZZZZZ@66.69.71.90:34202>">.
<status status="open" />.
</address>.
</atom>.
</presence>
The XML info is causing errors in the logs (which I've been ignoring for
now, but that's not really an optimal solution).
[...]
Other than forwarding presence information to a
presence-capable server
that understands the XML, is there anything I can do on the SER side to
Every correct XML parser should complain because the values of the
'uri' attributes are broken (double quotes and less-than sign).
ignore the XML stuff so I don't get a screen full
of error messages
every time a presence event comes through?
I wonder why the NOTIFY body is parsed at all?
Regards,
Olaf
3:27 p.m.
Olaf Bergmann wrote:
SIP wrote:
We route NOTIFY packets (after some rewriting to handle NAT scenarii)
along with SUBSCRIBE and PUBLISH to handle P2P presence without mucking
about with a presence server proper. Works like a charm... except for
this Grandstream. The grandstream is responding to a SUBCRIBE with this
wacky XML that's causing problems.
N.
There is now a Grandstream GXV3000 in my network
(neat little
videophones, I must say).
However, when someone sends a presence event through my server, the
grandstream responds with a SIP packet and additional XML info:
U 99.101.102.103:5060 -> 172.17.240.240:54330
NOTIFY sip:1101XXXXXXX@172.17.240.240:54330 SIP/2.0.
Record-Route: <sip:99.101.102.103;ftag=f0a1719429e37564;lr=on>.
Via: SIP/2.0/UDP 99.101.102.103;branch=z9hG4bK4204.13bfa134.0.
Via: SIP/2.0/UDP 66.69.71.90:34202;branch=z9hG4bK04c43fa29c41b774.
From: <sip:1101ZZZZZZZ@proxy.ourdomain.com>;tag=f0a1719429e37564.
To: "Jessa"<sip:1101XXXXXXX@proxy.ourdomain.com>;tag=1b55e40b.
Contact: <sip:1101ZZZZZZZ@66.69.71.90:34202>.
Call-ID: ZjczZGMzOWEzMTk0NjhkMzRjMjI3ODZkNzIwMGIxZDA..
CSeq: 1843 NOTIFY.
User-Agent: Grandstream GXV3000 (HW 0101, Ch:0) 1.0.1.7.
Max-Forwards: 16.
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK.
Event: presence.
Subscription-State: active.
Content-Type: application/xpidf+xml.
Content-Length: 342.
P-hint: LR.
.
<?xml version="1.0"?>.
<!DOCTYPE presence.
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">.
<presence>.
<presentity
uri=""Jessa"<sip:1101XXXXXXX@proxy.ourdomain.com>;tag=1b55e40b;method=SUBSCRIBE"
/>.
<atom atomid="1000">.
<address uri="<sip:1101ZZZZZZZ@66.69.71.90:34202>">.
<status status="open" />.
</address>.
</atom>.
</presence>
The XML info is causing errors in the logs (which I've been ignoring for
now, but that's not really an optimal solution).
[...]
Other than forwarding presence information to a
presence-capable server
that understands the XML, is there anything I can do on the SER side to
Every correct XML parser should complain because the values of the
'uri' attributes are broken (double quotes and less-than sign).
ignore the XML stuff so I don't get a screen
full of error messages
every time a presence event comes through?
I wonder why the NOTIFY body is parsed at all?
Regards,
Olaf
6385
days inactive
6385
days old
2 comments
2 participants
participants (2)
-
Olaf Bergmann -
SIP