Olaf Bergmann wrote:
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
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.